Improving how we prioritize what to fix and work on next

Project management
#1

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
#2

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.

#3

regarding the project management, are you able to get to this link?
@keunes https://github.com/AntennaPod/AntennaPod/projects

I could a good kanban board with 5 columns

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

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?

#5

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.

#6

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.

#7

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
#8

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.

Prioritize

Thatā€™s basically the same as the current versionā€™s milestone

WIP

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

Review

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

Done

All closed issues/pull requests

Shipped

This is covered in the release notes (or the ā€œmasterā€ branchā€™s commit history)

#9

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.

#10

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

1 Like
#11

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?

#12

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:

#13

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

1 Like