Define and document a process for creating, evaluating, and prioritizing roadmap items

[gusaus]

We need to document a process for creating, evaluating, and prioritizing roadmap items. Ideally folks from other, more established teams might have some knowledge or templates to share.

[gusaus]

First off, apologies for the incomplete issue description. While I think having some sort of standardized process (in our handbook?) would be helpful... we'll need help and guidance from our reps and other community members with knowledge and experience creating something similar for their Teams.

[YellowlimeNL]

What is common use to prioritize issues here at Github?

[CeliGaroe]

I have checked some projects boards from this link in training group and it looks like everybody does their thing:
https://make.wordpress.org/training/handbook/training-team-how-to-guides/how-we-use-github/

Like:
https://github.com/orgs/WordPress/projects/104
https://github.com/orgs/WordPress/projects/53

We can set up labels and columns (steps) of our own, well described on how to use them, and work with them. I we leave the instructions in written and then add to the team handbook it will be easy to follow.

[gusaus]

Seems like we'd really benefit from having an experienced, GitHub savvy, project manager and/or mentor on the team take on this responsibility. We're probably one of many (which could create an opportunity for contributors to work across multiple teams).

Mentioning this as it looks like a good bit of meeting time is being spent experimenting and learning on the fly. The result is a somewhat crowded/confusing roadmap.

My suggestion would be 1) only have 'projects' on the existing roadmap and 2) create a new project (Sustainability Project Tracker or some other name) for admin tasks. OR we just leave admin tasks off the project board but create more labels that describe status.

But this is coming from someone winging it or learning by contributing to multiple GitHub orgs and repos.

[noraferreiros]

I personally would use a project/issue as a test (handbook or welcome box, for example). I'd focus on it and try one way of organizing the work (what @CeliGaroe proposes seems good to me). And I'll define what works for us on the go. We are not so many active people at the moment, maybe we don't need so much pre-planning.

[gusaus]

Circling back to this issue as it should be much easier to contribute once a clear process is defined and documented in the handbook #5

As noted in the (incomplete) description and previous comments, I think we should seek out mentors and/or experienced project managers that have expertise from other teams.

It's great that team reps and some other folks are taking the initiative to wing it, but project managing shouldn't be a requirement.

[gusaus]

Until we find some expert help, we should log related improvements and suggestions in this issue. Here's a couple -

• the focus area labels are great! could we make them lowercase to be consistent with the other labels? also I think economical should be shortened to 'economic'
• after looking at some other projects in the WordPress repo, I took the initiative to wing a few changes to https://github.com/orgs/WordPress/projects/134
  • changed the first column to 'Evaluating' and modified the description; then moved a couple projects into that column
  • modified the description in the "In Progress" column so to clarify that only 'Projects owned or led by Sustainability team members that are actively being worked on.' should be in that column
  • created a 'Contributing' column for Projects owned by other teams or working groups we're contributing to; I then moved several projects into that column; considering those are active projects, there could well be an existing issue (and team!) in other repos; if there are we can reference those and close out issues in our repo; I'll take on the task of going through each issue in this column.

If we end up closing out five projects, even this view will seem a lot less daunting! project Project on our roadmap

[oldrup]

Oh nice @gusaus - now I feel at home 😊 Great job!

[LittleBigThing]

Concerning the labels:
I wanted them to stand out between the others, in doubt about uppercase. Maybe the color and perhaps capitals are enough differentiation? Check for 'economic', thanks!

[gusaus]

Referencing @CeliGaroe's suggestions from this related discussion as they're well aligned with other suggestions in this issue:

• Adding issues to the roadmap (redirect new members from slack meetings and handbook only to it, not to the issues):
  • Before any person adds an issue to the roadmap, this issue should have a leading person or persons that are willing to work on it and move it forward. Having a person that can invest a bit of time in that issue helps set up what to do and how to do it in the issue's comments, what guide and facilitate new members to join.
  • Set a time window to remove an issue from the roadmap is it has been inactive too much: 6 months?

• Most active projects on our Roadmap (either in the 'In Progress' or 'Contributing' columns) are self assigned and have a project lead. We should review any than don't (currently just Review sustainability tags used at WP Plugin directory #8) and see if it's actually active and make sure it's assigned to whoever is leading.
• I think we should encourage contributors to submit project ideas (especially once we document a process) just as long as they're properly labeled , categorized (in either the Evaluating or Todo columns), and referenced in meetings.
• If every active project has an owner/manager + is referenced in meetings, I don't think projects will go stale.

[YellowlimeNL]

Concerning the labels: I wanted them to stand out between the others, in doubt about uppercase. Maybe the color and perhaps capitals are enough differentiation? Check for 'economic', thanks!

First character as uppercase gives the issue page a better overview. Would be great to apply it to all labels @LittleBigThing

[YellowlimeNL]

May I suggest to add new issues to a backlog and to move those with little tracion to the backlog too. For better overview, ideally I wouldn't list more then 10 issues at the issues overview page.