Milestone management (current status quo)

[alerque]

Since I noticed @Omikhleia you added some things to milestones, here is an FYI on how I've been handling milestones lately...

The more things pile up in the next milestone the less motivated I am to plow through the busy work and land it. I'm trying to set exact version milestones only for issues that are either hard blockers before moving on or issues that have known solutions that look promising. Anything else—whether it might be an easy fix or not—is marked as being either in a .x.y slot for "the next patch release as soon as we have a fix" or .x.0 for "the next major release as soon as we have a fix".

That keeps 4 milestones buckets open for most issues:

• The very next next minor release with a known set of changes that will land, mostly because we've already figured them out.
• The next major release with a pre-planned set of breaking changes.
• A future minor release, whatever the next number happens to be when we eventually figure them out. This could be the next release or some later one depending on contributions. Issues in this milestone will constantly be updated to a concrete milestone when a fix is found or they are considered so urgent that we couldn't land anything else without them.
• Some future major release, whatever the next one happens to be when we sort out the details. These issues will also be updated with a concrete .0 milestone as soon as we plan how the breakable is managed.

I've found this split between things that will land help actually get releases out the door, meanwhile the triage between major breaking and minor non-breaking fixes and features helps think through where we're going.

[Omikhleia]

The more things pile up in the next milestone the less motivated (...)

Oh I understand that too, no problem -- and I agree with the rest of your post!

All the things I've tentatively added to 0.14.9 so far are things that I assume we can indeed solve in a decent time-frame from now: either because we already have potential PRs, or because the issue analysis points towards a solution (e.g. #583 and ##1528 since they happen to relate - I am heading toward an understanding on these, with bits of code in the discussion... and on my viewpoint, it's kind of a hard blocker¹ really worth fixing - And a PR might not be that far. It "looks" promising, no?)

Actually, there are a few things I would gladly move out of 0.14.9, to alleviate it. E.g. #1470, as I have my own doubts on it as later stated in the existing PR on my own initial approach, and it can be delayed IMHO -- but I hesitated moving them as you had previously set the milestone, so perhaps you think it's achievable? I dunno, but if not, AFAIC, feel free to phase it later (to 0.14.10 or even 0.15, for instance)... Likewise, if it indeed alleviates the task, we could reschedule #1699, #1721 and #1705 a "bit later", as the proper solution and the related PR are not yet there (so we don't really have "figure them out", to use your own words) and may need time, but aren't blockers (Well, #1699 could be one, but the directions towards a real fix aren't clear IMHO.)

Feel free to comment if any of my latest additions to the 0.14.9 scope feels inappropriate. My own way of thinking is that it's very motivating if we can kill these issues ;)

Footnotes

1. In the (slightly exaggerated) sense that they relate to, say, "SILE can't line break / justify / measure things properly"... ↩

[alerque]

No worries, I wasn't complaining about a particular issue being added or not. I just saw my todolist grow overnight and wanted to make sure we were roughly on the same page as far as milestone handling. The sliding "next" milestones are not my own invention –quite a few projects use something similar– but I also don't think it's necessarily very obvious to non-developers how I've been using them.

If it would make development work easier we could also start a development branch for the next major/breaking release and maintain master as the branch for the next minor/non-breaking release. Development PRs that can only land in a breaking version could be merged there, and all other PRs could be merged to master, then master merged (with any necessary conflict resolution) into development. This would give us an easier way to work out kinks in major changes without so much PR shuffling.

[Omikhleia]

Some comments here on 0.15.x

• I've started (again 🤣 ) piling up things to the next milestone: as usual, these are things I think are doable in a reasonable time frame (either having existing non-breaking PRs ready for review, or which would be easy to do once other PRs are merged, if time allows it).
  • IMHO that's a good way to see what a milestone is going to possibly be, and even have a vision on its scope and purpose. Having scope and purpose is great!
  • If need be, of course, we can alleviate the milestone by moving some of these things out, if they need more time to mature. It's an attempt to se a scope, but this is FOSS... So there's no obligation whatsoever on meeting fixed deadlines.
• After having done some "triage" on old bugs and really old PRs with conflicts...
  • I closed some of them directly. Triage is important in any software. Sometimes, things long unaddressed need new minds and ideas to occur, anyway.
  • I also added a label pending closure Backlog cleaning (inactive non bug-issues) for many old PRs that should perhaps be discussed one more time before being closed as "inactive" and no longer applicable to the current code base as-is.

Regarding triage, I hope we'll all agree that it's the way to go, though of course opinions on the matter may differ. I tried to be polite and clear in the "closure" messages (though this is not the thing I'm best at 🤣 ), taking some time to add dedicated comments in several of them.

Some notes on my rationale behind this.

First, everlasting draft PRs are (in my view) a bit detrimental to how I regard a software without going into the detail, just browsing it out of curiosity... It's either the owners don't care, or can't follow up, or don't know how to say "no", but it's rarely a "good sign". Some very old stuff didn't make it? Sometimes there are very good reasons, but leaving the PR open indefinitely does not help anyone...

Second, I adopt that "rough" viewpoint whenever I "visit" a FOSS project:

1. How many active contributors are there, on average, in the past year? Call that α, filtering out 1-time committers or activity on a very brief period of time.
2. How many open issues (N) and open PRs (P)?
   • Are there more open issues than 50 × α? If so, it sounds bad to me. 50 issues per active contributor per year is already a lot for an unpaid hobby. We could discuss that number, but as a rule of thumbs, it's not going to happen...
   • What is the ratio P ÷ N? If it's not around 10%, it doesn't sound very good to me... Lower (so many bugs, but few PRs)? Sounds bad! Higher (so far too many open PRs)? Sounds bad!

As said, these are rules of thumbs that not everyone would agree upon.
And if SILE currently has 270+ bugs for ~2 contributors on average, so be it... (It never prevented me from jumping in, after having tried it nevertheless!)
But then the number of open PRs should "ideally" be around 27, round that up or lower. And triage is important 🎬