Managing Enhancement requests

[jamesp]

I was learning some javascript development in my spare time (don't judge me) and came across this pretty interesting approach to managing the backlog of enhancement requests.

See 11ty/eleventy#117 as an example of how it works. In summary:

1. All enhancement issues are labelled as an enhancement, and then closed.
2. Users are invited to +1 the enhancements they would like to see prioritised
3. A linked issue filter sorted by number of +1's is used to review the list and see what needs to be worked on next.

What do you think? Could be something to learn here about how we manage our backlog?

[bjlittle]

@pp-mo How does this compare with your https://vote.biglybt.com/SciTools/iris/Feature:%20Voteable ?

It would certainly address closing down issues quickly, rather than them lingering around going stale.

[pp-mo]

The problem with that scheme was always getting it noticed.
You have to go to the labels page to find a link to the voteable issues.

[rcomer]

I think it didn't really get a fair run. It could be linked from the README and/or the "Getting Involved" section of the docs. Could also be periodically advertised on the Google Group (or whatever replaces it) and MO Yammer.

[rcomer]

To me, it just doesn’t seem very intuitive to have closed issues that we are still potentially going to work on. We’ve also already had a discussion at #4131 about closing issues being perceived as unwelcoming and putting people off.

I do like the idea of making it more obvious what an issue needs to progress though. We have a “needs info” label. Perhaps a “needs votes” and/or “needs volunteer” label might be useful. Our “good first issue” label seems to have been quite successful at attracting new contributors.

[rcomer]

Just some thoughts about the wider picture for Iris, which I think should be considered when thinking about how to manage priorities. I'm afraid they don't come with any suggestions attached!

Looking through our currently open enhancement issues, the majority of them were opened by core devs. Users within the Met Office tend to engage with devs in others ways than GitHub. We even have a spreadsheet recently set up by @ehogan to try to capture internal development priorities. I believe at least some issues have associated internal MO tickets too.

We have an ESMValTool label, presumably because we see ESMValTool issues as priority. Would this label negate the need for votes? I'm guessing the ESMValTool team could probably muster the votes if necessary anyway!

[trexfeathers]

@rcomer agreed this is a core problem.

• Any GitHub voting solution will push for software that meets the needs of those who best engage with the open source model.
• One of Iris' core strengths is that it works for users who do not have time to be software experts, and these users by definition will not be willing/able to engage with GitHub development discussions.

It's easy to forget about the 'novice' user base since we by definition have less contact with them. So long as they are a key user base, then the only way we can know what they need is to invite less developer-ish contact such as questions, help requests, and the MO spreadsheet. And often we'll need to do some extra work to convert such contact into information on development needs. IMO it's important to keep targeting Iris at this audience, but if not then that's a different discussion.

[jamesp]

Great points @rcomer and @trexfeathers. I'm not sure how effective a voting scheme would be for us if we only get O(1) votes on enhancement issues - not a lot of signal to go from!

Voting may not be the right solution. Perhaps the experiment with https://github.com/bjlittle/stale/issues will show some interesting new ways to think about the backlog.

[tkknight]

I agree, having a clear way on voting on enhancements (or bugs) would be very useful.

If put in place we would need to ensure the Iris docs make it clear how to vote, or pinned issues/templates explaining too.

[trexfeathers]

See Dragon Taming