drop's picture

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?

Most helpful answers

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

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.

Comments

What about this...

Allow nominations from the community for things they'd like to see fixed/added in the next version of Backdrop. These can be existing bug reports/feature requests, or new things (that would then have an issue created). Set a date by which nominations need to be in. Then allow a period of time for the community to vote on the nominations. This would end on or just before the release date of a minor version of Backdrop, and so then the community/developers/PMC would know what to work on as a priority for the next version.

For example:

  • 16th April 2020: Nominations open for v1.17.0 priorities
  • 30th April 2020: Nominations close and voting begins on v1.17.0 priorities
  • 14th May 2020: Voting closes
  • 15th May 2020: v1.16.0 released, and results of vote determine what priorities are for v1.17.0

These priorities would not be set-in-stone (e.g. we wouldn't be advertising "version 1.17.0 will include these features..."), but would just give an idea of where effort should be focused. 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).

jenlampton's picture

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 haven't thought too much about it, but I guess I was envisioning a dedicated page/place for this (like webforms for submitting ideas and voting on them, or dedicated issues for the same).

Currently, looking for 'nominated' issues means finding your way to this page/filter: https://github.com/backdrop/backdrop-issues/issues?q=is%3Aopen+is%3Aissue+label%3A%22milestone+candidate+-+minor%22 And voted on issues here: https://github.com/backdrop/backdrop-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.16.0

Also, the current advocacy system requires an idea to have an issue before it can be nominated (as opposed to nominating an idea and then (someone else?) creating an issue for it) and also allows an issue to make it into the final priority list with only two votes (someone adding the milestone candidate label, then someone else converting that to the milestone itself)...

oadaeh's picture

Is there a way for people without a GitHub account to vote?

jenlampton's picture

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.

Maybe we should dedicate one of our weekly video sessions to this, perhaps the first one after each release, at least. 

Start by re-examining our potential market, deciding what features that market would require or have been asking for in a CMS, whether we provide those, whether we could improve on any existing strengths, then identify existing issues which help with those, and create new issues where we there are none.

If we decide on tags or some other way of identifying issue priorities, we mark these newly identified issues as higher priority.

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

klonos's picture

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.