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
1 Like
#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
#14

@tonytamsf @ByteHamster Hope you both are well. As noted in Expand Contribute by keunes · Pull Request #73 · AntennaPod/antennapod.github.io · GitHub, I think we need to make it easier for ‘external’ people to contribute to AntennaPod, and quickly identify things that we would greatly appreciate help with.

I would organise it by big topic/area that support from external contributors would be very welcome. I’ve created a new project with different boards:

Curious if you think this could work/help, or if we should organise the board differently to make it easier for externals to find things we most need help.

2 Likes
#15

I feel like there are a lot of outdated and also some support issues that somehow no one is responding to anymore, so maybe they could be cleaned up as well, maybe as part of https://forum.antennapod.org/t/antennapod-hackathon/

AntennaPod Hackathon!
#16

I, personally, do not really plan to manage it but maybe it helps new developers :slight_smile:

I usually clean up the issues 1-2 times a year, so I think only the recent ones could need cleanup. Most old ones should still be relevant.

#17

Ok, didn’t look that much into it but there are a few from 5y ago, maybe it makes sense to close some of there’s no progress for about a year expect if it’s an unfixed but or a feature suggestion.

And maybe some support issues could be redirect to the forum to only have the coding relevant ones on github, but you probably thought about this already, don’t mean to interfere your workflow or anything :smiley:

@keunes maybe all feature requests/enhancements from the issues could be listed in a TODO with some prioritization, would be a lot of work probably

#18

Well, it’s not targeted at you :wink: I would think it contains the items that you and the other already active contributors won’t work on, or would need help with.

And so the list should be rather short (remember the point was to make an easy point of entry with clear pointers of what could be picked up), and most probably be rather static (as what we put out there won’t very likely be picked up quickly, otherwise it wouldn’t have lenses up on the list in the first place).

I think that kinda is the idea already, but we could be a bit more explicit. For example, we could creat ‘Support’ issue template that directs users to the forum (rather than having the ‘forum’ as the title).

Also I’m wondering if Feature requests wouldn’t better fit on the forum, as they often first require further discussion. Then they could be ‘transferred’ to GitHub once it’s how it will be implemented and what the UI will be like.

I imagine that would indeed be a lot of work. And I’m not sure who would be using that list :slight_smile: