Improving how we prioritize what to fix and work on next

I see we have over 200 issues, I find the labels and milestones useful to find the next thing to work on as a contributor.

@keunes is doing a great job managing the backlog.

I am brainstorming other ways to manage the backlog

  1. Could we also turn on the Kanban board on Github, it has a better project management
  2. Could we also do a clean up of really old issues (> 3 years)
  3. Is there another way we can set priorities so I could see the top N bugs / features to fix. I love the confirmed bug tag. Maybe the 2.N version milestone is good enough

Wow. We still have 79 issues that are 3 years or older, of which 12 confirmed and 4 possible bugs.

I’m fine with closing old ones, but it would be hard for me to judge (as a non-developer) what can be closed and what not.

By the way, ByteHamster also did a great job recently cleaning up old issues :slight_smile:

I see there seems to be something as an “organization-wide project board”, but I don’t seem to be able to link my test project to any repository/organisation. Maybe I don’t have enough permissions (though I don’t even manage to link it to my own repositories).

Apart from that failed test, I’m not sure a Kanban board will be convenient: it feels a bit like overkill. Using milestones and/or (extra) tags seem easier to me.

regarding the project management, are you able to get to this link?

I could a good kanban board with 5 columns

  1. Prioritize
  2. WIP
  3. Review
  4. Done
  5. Shipped

Ah. I can, and I’m sleepy :sleeping:

The thing is: a project feels like overhead - extra work. What would be the benefit for you of a project over milestones and possibly a ‘priority’ tag?

Right now with 235 issues, it’s really hard to figure out what the maintainers and you think it’s important to fix. So that ‘Prioritize’ column is the most important one for contributors and for @ByteHamster to drive a certain stream of work.

The ‘Review’ column, I assume is good for @ByteHamster to know what he needs to review (but he does it well now with < 20 PR’s, so maybe that is not useful.

The ‘Done’ column is good for people to know what is Done but not shipped. The shipped column is good for beta testers to know what to try out.

Right. But a (simpler) ‘Priority’ tag would have the same effect, with less overhead work, wouldn’t it?

A ‘Review’ column could be handy indeed. Though it’s already possible to request a review per PR.

Such ‘Done’ column could be useful for end-users. But I’m sceptical it will prevent the creation of new issues for bugs/features that have been dealt with but not shipped yet. So it doesn’t really solve anything, just add overhead of moving issues to/from this column.

No worries :stuck_out_tongue_winking_eye:maybe we need to keep the issue list under 200, lable more so contributors can jump in

1 Like

Is there another way we can set priorities so I could see the top N bugs / features to fix

You can also sort the issues by the number of +1 reactions on the first post. That’s probably useful when looking for new features to implement. To be honest, though, I don’t care too much about the requested features. I mostly fix bugs. If I add a feature, it’s usually because I have a use-case myself. Not because it has X upvotes.

I could a good kanban board with 5 columns

To be honest, I also think that managing such a board adds too much overhead.


That’s basically the same as the current version’s milestone


Not sure we need to track those explicitly. New contributors regularly start something and then give up.


All open pull requests are under review :slight_smile: (or need some discussions about how to do it)


All closed issues/pull requests


This is covered in the release notes (or the “master” branch’s commit history)

Another thing that I was thinking: we already have Beta releases that we can test. But in some cases it’s useful to test a specific feature that’s been developed but not released yet, especially if it’s a more complex thing. I remember one PR from ByteHamster where I promised to help test, but I forgot which one.
Using Beta helps finding bugs/areas for improvements by running into things. But when it comes to testing new features in-depth it’s not the best method. Maybe a new tag ‘Help us test’ tag would be helpful? It can be applied where the developer wants others to download Circle CI builds and test the specific changes.

I just created a project board for tracking the state of PRs. Let’s see how that goes.

1 Like

Thanks for trying this, however I couldn’t drag my PR into “Waiting for maintainer review”, what is the best way to do that to put into your queue?

I must say that I am not using it at all (and that moving around PRs is a lot of work). I deleted the project board again and switched back to the old method of keeping track of open things to review: working my way through my email inbox :slight_smile:

Works for me :slight_smile: however you can get to PR reviews

1 Like