Revive milestones to group issues and features

[reneleonhardt]

When I see 500 open issues and 200 open pull requests I'm kind of lost.
The readme mentions experimental features like "Safe, concurrent replication".

Could issues be assigned to milestones and labeled in such a way to make it easier to contribute to the next releases?

I recommend enabling a free tool like CodeRabbit to request review help and merge all that work from your contributors faster.

[martinvonz]

Could issues be assigned to milestones and labeled in such a way to make it easier to contribute to the next releases?

Isn't that hard to do in open-source projects where people work on whatever they feel like? I've worked on the Git and Mercurial projects before. I don't think either of them had anyone planning features into milestones. Does anyone know if other open-source projects do anything like that?

[flowerysong]

It's not necessarily harder for open source projects, and can be useful even for volunteer-led projects. It depends on the development goals of the project and how the people involved like to organize things. It's probably more common for commercial open source products, but I've also run across it in other contexts.

However, it's far from the only method of providing direction to people vaguely interested in contributing (which is not, I would argue, a normal goal or even outcome of having milestones.) I think labels like good first issue and help wanted do far more to "make it easier to contribute to the next release."

[evmar]

I have no comment on whether it's a good idea for this project or not, but since you asked, here are some other projects that use milestones:

https://github.com/rust-lang/rust/milestones
https://github.com/ziglang/zig/milestones

I think a typical use is to be able to bucket bugs into "must be fixed before the next release" vs "fix soon but doesn't block release". I believe Zig also has some buckets for "would be nice at some point but aren't urgent".

[martinvonz]

We do monthly releases, though, so "must be fixed" rarely applies. There could be cases where we learn about a serious problem just before the scheduled release date, and in such cases we would presumably hold the release for a little while.

[joneshf]

Many projects do make milestones and releases one and the same, but they don't have to be. And for a project that uses time-based releases, it can very easily slippery-slope releases into being delayed (unless the maintainers are diligent about pushing things forward to the next milestone when the release date comes up).

Honestly, the way the two current milestones are setup (Submodules phase 0.9: Readonly submodules can be manually managed and Submodules phase 1: Commands automatically respect readonly submodules) seems like the way this project could use milestones for other features:

• They describe what the state of the project should be at the milestone.
• They have the issues necessary to get to that point.
• They have no due date.

The lack of a due date conveys there is no pressure to work on this milestone vs. anything else. But the milestones still show what progress has been made toward the feature. Once an issue is done, it's in the next release because the project uses time-based releases. If an issue is not done, it's not in the next release, but it also doesn't block the next release. If someone wanted to contribute to submodules, they could pick up one of these issues (assuming it's still accurate).

Looping it back to the original question, if there were a milestone for taking "Safe, concurrent replication" from experimental to stable, that might help folks like @reneleonhardt know where to contribute to certain features.

Other projects have like a 1.0 milestone, or beta/stable milestones, or next major version milestone, or something like that. Since zig was mentioned above, they have a pre-1.0 milestone. No due date on those sorts of milestones either. But they act as guideposts (or day I say, "milestones") for knowing how close/far the project is from something.

That said, given the connotations around the word "milestone" (and how it seems to evoke thoughts about being tied to releases) maybe projects align better with the original request?