How to better set priorities for Core Development?

First, thanks for the great topic :)

Allow nominations from the community for things they'd like to see fixed/added in the next version of Backdrop. 

We already do this. It's the "milestone candidate - minor" label. 

Set a date by which nominations need to be in. 

This is date is currently set to "shortly after the previous milestone is closed" because these issues need to be reviewed by the PMC. 

To that end, the priorities should be discussed during the weekly meeting (I'm not sure if they should replace or complement the existing 'advocacy' system).

You are describing our current system :) We added the issue advocate because if there is an issue that lots of people want, but that nobody is working on --surprise -- it doesn't get done.

Then allow a period of time for the community to vote on the nominations.

This is the only piece of your recommendation that we are not currently doing. Instead of a vote we are relying on comments on the issue, and discussion in the weekly meeting to determine interest. How would you envision the vote working? 

I'd also like to see some more big picture thinking, not so much "this issue needs to be worked on" but -- "What does backdrop need now, to be more successful?" Something that happens outside the issue queue.

I have two big thoughts:

1) I think that we do OK in terms of prioritizing new features (not great, but ok). Our current process does provide some time for us to discuss them in meetings for for individuals to advocate for issues that are important to them. BUT, I think that this is much room for improvement in how to prioritize bug fixes and finding ways to focus on some of the important but difficult bugs in Backdrop CMS. 

2) There was some discussion during last dev meeting about whether or not we discuss and create something like Drupal "initiatives." My understanding is that initiatives would differ from advocating for an issue in that they would be created around community priorities and potentially involve a small group of people working together to address specific initiatives. I'm hopeful that by creating initiatives, we might also be creating additional points of entry for new volunteers/contributors. 

I'll try and write more about what I think "initiatives" in Backdrop might look like before our meeting this coming Thursday. I look forward to hearing what others think.

As promised, here is what I took away from our discussion of "initiatives" last week. 

Goal: Provide more structure and incentives to work on issues that are determined to be important for the project. 

Possible Solution: Create PMC (Project Management Committee) approved initiatives to address some critical issues for the Backdrop CMS community. 

What is an Initiative? An initiative might have any or all of the following characteristics (to be determined). This is really just a list of ideas that came up during our conversation.

1. Might be one or more people that are collaborating to address a problem or issue that the community has identified and the PMC has approved. 
2. An initiative might be formed to tackle a single task, a category of tasks, or a specific need facing Backdrop CMS core or contrib space. Any of the following might be suitable for an initiative:
   1. Improving search in Backdrop CMS core
   2. Improving availability of contrib themes
   3. Create a system for triaging bugs and identifying which ones are most important. (This initiative might just focus on creating the system).
   4. Fixing the top 10 critical bugs in core (this initiative would do the work).
   5. Rework Color Module
3. Initiatives could schedule their own periodic meetings via chat or video conference and should attempt to recruit new people to participate (not just the same people on every initiative).
4. Initiatives might be expected to report back periodically during weekly dev meetings.
5. To be viable, every initiative should have at least one key organizer willing to organize activity.
6. Anyone can nominate an initiative, but the PMC should decide how many initiatives are viable at one time and which ones to focus on.
7. Every initiative should set goals for each release cycle and report back on goals. All initiatives should be reviewed each release cycle. Initiatives that are not making progress should be restructured or terminated in favor of other initiatives. 
8. We could time limit every initiative OR allow for ongoing initiatives. 

Potential benefits of initiatives:

• Additional points of entry into contribution to Backdrop CMS. Different initiatives might schedule alternative meeting times or reach out to different people for help.
• An initiative lead might be granted some authority to break deadlocks in the issue queue. The lead of a UX initiative might have some authority to weigh in on controversial UX discussions (if the PMC chooses to grant that authority). 
• Ability for community to focus resources on persistent problems that might not otherwise be addressed. 

All of this is the result of brainstorming and we appreciate additional ideas, discussion, or alternative suggestions. Also - it is unlikely that initiatives alone will resolve the problems raised by @docwilmot - but, they might be part of the solution.

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

thanks,

~Geoff

One idea that was thrown around on Gitter was to add some sort of "priority issue" label on GitHub (similar to the "good first issue" one we already have), and then assign that label to a specific set of tickets.

Here's a few more ideas on that:

GitHub already supports "pinning" up to 3 issues:

...so perhaps we can use that feature, to prioritize up to 3 META issues at each given point in time.

Each META issue can have multiple "children" issues, and because these can be reordered at the issue summary, we can use their order as a means of prioritization.

In other words, we could have those 3 pinned METAs be some sort of "initiatives", same as those in d.org: https://www.drupal.org/about/strategic-initiatives

If reordering the issues/tasks within each META does not work, then as an alternative we can use GitHub "project boards" for each META: https://help.github.com/en/github/managing-your-work-on-github/about-project-boards

I think that which 3 issues are pinned should be a PMC decision (after discussion with the community ...and perhaps also after allowing the community to vote).

This method will allow us to take advantage of already-existing features in GitHub (so people won't need to be tracking yet another queue, or use an "external" tool). The downside is that we won't be able to cross-prioritize issues across say https://github.com/backdrop/backdrop-issues/issues and https://github.com/backdrop-ops.
 

As a test, I've pinned 3 META issues (based on most comments). Here's how it would look:

On Gitter:

> In our github issue queue we have an optional label 'good first issue'. Could we not have another label 'priority issue' ...

I like the idea of priority tags.

I also support the idea of the PMC making firm decisions, including for, example, casting a deciding vote on how issues are to be tagged, and when asked to weigh in on out-of-hand issues (too long, too undecided, too heated etc). If we can agree that the PMC are not going to be too autocratic,  and be willing to re-consider where there seems to be majority consensus.

To me this is not just a group making good software. It is also an organization which needs to grow. I feel We cannot all make the hard decisions.