In another topic on setting goals for 2020, @docwilmot raised the issue of finding better ways of setting priorities for core development. It has been suggested by some members of our community that this is a conversation that deserves its own topic. So here it is. To start the conversation, here are a few excerpts from the @docwilmot's original post.
For example, Drupal has methods of setting priorities for core development: there are 4 possible (mandatory!) tags on issues (critical, major, normal, minor).
There are also the "favorite of ..." tags which may give an idea of the perceived priorities of the main leaders of the organization.
We don't currently have an effective prioritization system. Devs pick their favorite issues and contribute PRs, then hope that someone else will review it, but due to our small group size, that someone else very likely has some other issue(s) which is his/her favorite. We can also advocate for an issue, that simply tells others which issues we prefer. We have milestones; if an issue is not concluded by a milestone, we simply bump it to a new milestone, or remove the milestone(!) regardless of how significant it may be.
None of this allows any group consensus or discussion on which of these may be critical to Backdrop's development and future.
What are your comments or suggestions regarding setting development priorities?
Specifically on developer contributions. I'd like to see the issues discussed on a high level separately from the dev queue.
I've always had this problem in Drupal and Backdrop where the issue queue has a lot of opinions and possible solutions, but no clear direction. I know that I get the most gratification when working on the code of backdrop and experience great satisfaction when something is committed.
On the flip side I experience great frustration when I work on something and it turns out it was not ready to work on it needed
* design (UX and otherwise)
* it has many opinions that were not expressed until after development
then the issue slogs, bikesheds, and no one (typically) makes a canonical decision.
For example see https://github.com/backdrop/backdrop-issues/issues/2353
Which is a simple issue and one I'd typically be over joyed to spend an hour or two on a Sunday, researching, solving, and commiting/PRing, but this issue suffers from lack of direction and specification.
If we discussed an issue like this and others in `backdrop/backdrop-issues` and then once the PMC says yes this is the direction we could then have the PMC open a new issue in `backdrop/backrop` where the PMC can reference the original proposal, but the OP of the issue in `backdrop/backdrop` signals to developers that:
1. this is issue is/has been discussed and is ready and approved for dev
2. this is the spec not a moving target
Of course if formal initiatives are identified those could move to `backdrop/backdrop` too as projects once they are approved by PMC