I must admit when I use Milestones in GitHub (different, but analogous), I
will put any upcoming or recently fixed issues in the currently active/in
development milestone first. For Haiku that would indeed be beta2. It makes
it much easier to see progress if anything closed whilst working on beta2
(no matter its original target release milestone) appears under the
'current' milestone.
It's also logical from a time perspective. Beta1 is released, and thus all
fixes happen 'after' that particular milestone. Even if it's a hotfix for
beta1 it doesn't really make sense to put it under the beta1 milestone as
it gives the erroneous impression this fix was always in beta1.
On my projects I tend to have new tickets not have a milestone, and tickets
either get closed (not a bug, duplicate etc.) immediately, or gets assigned
to a milestone for fixing. On larger projects you may wish to tag them as
'triage' rather than automatically tag the current/next release.
Just my thoughts.
Adam.
On Thu, 22 Nov 2018 at 11:28, Adrien Destugues <pulkomandy@xxxxxxxxxxxxx>
wrote:
Hi there,
I find the current use of milestones a bit unpractical and would like to
suggest some changes.
Current status:
- Tickets get into the R1 milestone by default
- Whenever something needs ABI breakage, it gets moved to R2
- When something is a "not R1" thing (eg. multiuser), it gets moved to
Unscheduled
This is all fine. However we also have milestones for alphas and beta
release.
It would be very convenient if we could get a good idea of what the
changes from beta1 to beta2 are, just by looking at closed tickets in the
beta2 milestone. It would also simplify extracting stats for release notes
("over xxx tickets were fixed in this release" or the like).
As a result, I think closed tickets should be moved to the next milestone
(currently beta2) instead of staying in R1 or Unscheduled. This will give
us a better overview of our progress, I think?
--
Adrien.
