Applying some Prioritization to Issues and Milestones

[chrisdebian]

Hi, all.

I see we've got a lot of open issues. Can we apply some business analysis/ prioritization to these, to inform new releases? This should be fairly straightforward and would help to make maintainability a bit more structured. Happy to look at this, but someone in the project will need to make some prioritization decisions.

What do you think?

Chris

[nicolas-raoul]

Hi Chris!

You are right, we have a lot of issues, big and small. From urgent bugs to the most niche feature requests, all are welcome to stay open until the day some developer takes a personal interest in them. :-)

As you may know, none of us is getting paid, so what gets done really depends on what developers have interest in.

Disinterested developers can pick the most urgent issues from the top of this list:

• Issues marked as high-priority by the project maintainer or a core developer
• Bugs with most upvotes
• Enhancement requests with most upvotes

Other ideas on how to organize issues are welcome! Of course, please also feel free to upvote issues that you want to see solved. Thanks! :-)

[chrisdebian]

@nicolas-raoul Thanks, that's helpful. Let me have a think about the options/ possibilities. I'm very mindful of the project being worked on by volunteers.

Thanks,

Chris

[chrisdebian]

Hi, @nicolas-raoul and all the values project devs.

I've created a spreadsheet to take some of our bugs, enhancements and other priorities, and want to assess them using the MoSCoW method; to help encourage developers to do stuff they are interested in, and to give us release targets to aim for. To see how this is received, could I ask any of the devs to have a look at the spreadsheet that i've created, and in the column with your name, put one of the following, which will indicate how important (or not) you think the item (bug/ enhancement) is.

For each item, to help prioritize, we have four options:

M= MUST HAVE
or
S= SHOULD HAVE
or
C= COULD HAVE
or
W= WILL NOT HAVE (at this time)

If you are interested in the direction of the project, please put M, S, C or W in your column. This is the background to MoSCoW, if you haven't used it, before.

Let's give it a go, and test and adjust, as we go along.

I've got the list of Devs from GitHub's idea of who has contributed, recently.
Obviously this doesn't cover all the bugs or feature requests/ enhancements, but it does list the most 'upvoted'. If we like how this works, the spreadsheet (or similar) can be moved somewhere else.

Thanks,

Chris

[chrisdebian]

@nicolas-raoul Thanks for having an initial stab at this. All we need is one person to express a preference, in order to be able to prioritize things, but as we all appreciate, @nicolas-raoul isn't the only contributor, here. Does anyone else want to have a look?

Thanks,

Chris.

[neeldoshii]

Hi @chrisdebian, how about we implement the same in using Github Board (Kanban) which will take the issues from github issues. I think marking it on Excel manually we might face inconsistency when we have more issues. At Github Board if I believe we can have visuals that this issue is marked as completed and completed and how much count is left for this release. What do you think?

Check this link : https://github.com/orgs/OpenArchive/projects/4

[chrisdebian]

@neeldoshii Hi, Neel. Love this idea. Currently the Kanban is missing a link between the Backlog and the 'Doing'. More than happy to move to an established Kanban, but just checking 'buy-in', this way, initially.

Thanks,

Chris.

[parneet-guraya]

Hi @chrisdebian nice that you're trying to improve contributing experience, appreciate that. Could you give me access to the sheet, I wanna try it out :)

[parneet-guraya]

Nice, I like it. I'm guessing this is going to be updated manually?

[chrisdebian]

Nice, I like it. I'm guessing this is going to be updated manually?

Initially, but the thing is to get the process working, then automate it, ideally. We just need to get to the point where we have bugs/ enhancements associated with releases/ milestones.

Thanks,

Chris.

[neeldoshii]

How about we add all issues which are mainly focused for released in ours( https://github.com/commons-app/apps-android-commons/milestone/11) and their (https://github.com/ankidroid/Anki-Android/milestone/67) and each issues have labels suggesting the priority or detailing whatever works best? WDYT?

[chrisdebian]

Go for it!

[chrisdebian]

How about we add all issues which are mainly focused for released in ours( https://github.com/commons-app/apps-android-commons/milestone/11) and their (https://github.com/ankidroid/Anki-Android/milestone/67) and each issues have labels suggesting the priority or detailing whatever works best? WDYT?

I'll try to look at these, this afternoon, between meetings. WRT Anki-Android, that looks like it needs organizing, but android-commons is what i'm here for.

Chris.

[chrisdebian]

Wow, just looked at the milestones. Most of the items aren't "Issues marked as high-priority by the project maintainer or a core developer", "Enhancement requests with most upvotes", or "Bugs with most upvotes".

I'd really like to help organize things here, but I think people are pulling in opposing directions, with regard to the priorities. If the Deliverables for the next milestone are not listed in any of the criteria that @nicolas-raoul mentioned above, what is the rationale for milestone inclusion? I think some project governance needs to be established.

Everyone is trying to do the right thing, but it doesn't seem to be coordinated.

Do we have a link to a page saying how we prioritize things?

Thanks,

Chris.