Open monkeypants opened 6 years ago
Note: in a master/slave milestone situation (per #17), the autosprint behavior would be configured on the master. The slave milestones would mirror the behavior through following the events on the master, there is no need for them to also do the autosprint milestone close/create etc.
The exception to this is that following repos will need to move their "did not finish" tickets into their own sorting hats. To know that they need to do this, they will need to know that they are following a master with the autosprint gnome-opinion, and inherit the behavior somehow.
How do we define the "current" sprint. Is it any milestone that has yet to expire?
For sequential sprints, given there's no "start" date, we may need some config/rule that says:
if config.sequential:
milestone = get_milestone_after_last_expired()
else:
milestones = get_open_milestones()
By the definition of the original pseudocode, the only suggestion I'd make is:
chose the open milestone with the most-recent completion date as "current milestone":
gets rejigged to be "with the closest future completion date"
I think the original conditions has a typo:
if there is an open milestone with a finish date/time in the future: close it
This should be "past".
per #17, if a repo has
.bugflow/autosprint.yaml
, then...and