It’s 2016! And we’re accumulating rather a lot of issues in the Github tracker. We have labels to indicate what an issues is (bug, enhancement request, etc) but nothing really for planning or prioritization. Being a small band of enthusiasts doing stuff on our free time we’re obviously very light on the whole planning business and it should stay that way. Nonetheless I’d like to make visible the planning that does exist.
I’ve added a few milestones (the only other dimension that exists in the Github tracker apart from labels), listed below. These are the milestones/planning stages I consider important - but I’m posting this here to get opinions and feedback. When I talk about “issues” and “resolving” below it applies equally to bugs and features.
The Planned milestone, for things we intend to do soon. Here are the issues that someone in the core team cares about and wants to resolve sometime in the near future. This is as close as we’ll ever to get to answering the common question “Do you plan to add … feature?”. If it’s in here then yes. This is an eternal milestone, with issues coming and going. Adding an issue to this milestone is a declaration of intent to work on it. This could also be called something like Next, Backlog, …, ?
Then Unplanned milestone, for things that would be nice if they happened, but no-one has any plans to take care of it anytime soon. This is either stuff that is long term, or just low priority stuff that we don’t have the time and energy for right now. If you disagree with this, the best way to make something happen here is to work on it yourself. This is also an eternal milestone.
Major version milestones, i.e. currently v0.13. No change here. These hold issues that should be in that release. This will usually be major, breaking things, so seldom more than a couple of issues or pull requests. We create a new major milestone when we do a release. In a sense it is like Planned but for things that can’t just be resolved and released without some coordination and a version bump.
Issues lacking a milestone are still undecided, i.e. we don’t really know yet how important or difficult it is, or if it’s a bonafide bug or a configuration error and so on. I’ll go through these periodically, and things that are valid get added to the Unplanned milestone. When doing this I’ll also try to clear up the issue titles so these are clear and actionable.
I try to add people to the team after a few good PRs, so there are more people that can help juggle these things. If you are on the team and do plan to work on something, please do use these milestones to reflect that.
There are some labels that I’m not sure add any value; mostly those that we set on pull requests. The pr-WIP label is good as a “don’t merge yet!” indicator, but I’m not sure if we have any real use of pr-bugfix, pr-refactor and enhancement (as it applies to PRs)?
Would it be appropriate to simply call the milestone Unplanned (Help Wanted)? Or Unplanned (Contributions Welcome) or something? I don’t want to keep changing the names, but we can bikeshed this for a while now when it’s new.
Heh, renaming milestones is really not super well handled by Github. It’s not reflected as a comment, and the existing “Added the Unplanned milestone” links become 404s
I like that concept of staging tickets to reflect that somebody has already read them and they are considered valid. But I don’t like the term “unplanned”, I think it is a bit misleading.
In what way? There’s a quite intentional piece of expectation management here in that many of these issues are things like feature requests that will literally never happen unless someone new joins the project and takes care of them. Others will happen for sure, but we don’t know when we might be able to get around to it (it may take years; some have, already).
I just think that for instance “accepted” or “valid” would make more sense than “unplanned”. “Unplanned” sounds too negative to me, a bit like “trashbin – we don’t like these tickets”; but that’s just my opinion. =)
Hmm. I think usually there’ll be some amount of discussion involved and not just dumping it with a milestone. Although I see that I did just that earlier today. :/ Sorry, bug reporters, correcting that now.
But let’s say that the flow should be a human response of some kind, the addition of a label (enhancement or bug usually), possibly a clarification of the title, and addition to a milestone (planned or unplanned, however we name them). I do want the latter to give some sort of explicit “don’t hold your breath” indication; for the original requester, but also for any passersby in the future.
Fully agree. The IMO simplest solution is assigning a tag to the appropriate tickets (of course we should not create too much different tags…). You already tag tickets for a long time, so the human response part is already there.
If you decide to tag issues or instead use github milestones … does not really matter I think. Milestones on github feel pretty much like additional tags, so there is not so much difference there. I personally prefer keeping milestones as milestones, say use them for particular Syncthing versions; tags instead could be used more dynamically. But we should keep them minimal, otherwise it will be a big pain in the ass.
Here is a suggestion for a tag based workflow:
Untagged tickets are the “inbox”. Nothing special here, nobody is interested in these tickets (or had the time to read them).
Assign a tag (Bug, Feature, RFC, …) when a ticket has been verified/reproduced/… by a Syncthing developer or just sounds interesting. Valid tickets represent some kind of “filtered inbox” for interested contributors.
Do not assign “invalid” when the ticket contains crap; just close it.
Assign “dup”, crosslink and close when a ticket is a duplicate.
When a ticket is “planned” (explanation see first post in this thread) assign a “planned” tag.
The Github issue tracker provides some powerful filter stuff; appropiate links to the filtered issue list (= tagged issues) can be provided in the Contributors guide.
Well, I have written that stuff above and now I realize that it is almost exactly the same workflow when you use milestones instead… Anyway, maybe you find my braindump interesting.
What you’ve described above is essentially our workflow, yes. Even down to not having the invalid labels and so on.
The reason I like milestones for this is that they represent the trackers either-or concept; if I add an issue to the unplanned milestone it is automatically removed from the planned milestone. If we for example had planned and unplanned labels this wouldn’t be the case. It also enables searches like “enhancement label, but no milestone” while you can’t search for “enhancement label, but none of the planning labels”. How often that’s actually necessary is maybe debatable…
We could be more fine grained though, if we wanted to.
Planned (this is happening, soon)
Unplanned (or maybe Accepted?) (we want to do this, but we’re not sure when we’ll get to it)
Contributions-Welcome (this is a valid feature, but no one currently involved wants to implement it)
I don’t see us using milestones for actual releases apart from the occasional major release, as we’re quite fluid and cut a release every week.
So I’ve stayed with the Planned and Unplanned (Contributions Welcome) phases. I think what goes into Planned will vary a little depending on who puts it there, but for me at least it’ll tend to be things I intend to get to fairly soon. I’m fine with people putting things there that they don’t get to until a few months later as well, but after that it should probably go back into Unplanned.
We don’t want to put too much effort or precision into this. I haven’t yet seen an organization where developers regularly update tickets to their current status, even when they get paid to do so (and we don’t), so I don’t think we would be awesome at it either.
If we did want to get more precision into it I would suggest adding something in front of Planned, i.e.:
Current (working on it, will get into one of the next few releases)
Planned (want to do this sometime, maybe in a year)
Unplanned ... (don’t want to do this, someone else is welcome to)
But like I said, at this point I don’t think we’d maintain Current well enough for this to make sense.
And we’re accumulating rather a lot of issues in the Github tracker. We have labels to indicate what an issues is (bug, enhancement request, etc) but nothing really for planning or prioritization. Being a small band of enthusiasts doing stuff on our free time we’re obviously very light on the whole planning business and it should stay that way. Nonetheless I’d like to make visible the planning that does exist.
