bugflow / auto-gnome

GitHub Ticket Gnome
https://auto-gnome.readthedocs.org/
0 stars 1 forks source link

autosprint: create project boards that track the current milestone #18

Open monkeypants opened 6 years ago

monkeypants commented 6 years ago

per #17, if a repo has .bugflow/autosprint.yaml, then...

periodically (10 minutes?):
    for every repo with autosprint feature enables:
        if there is an open milestone with a finish date/time in the future:
            close it
            if there is no "sorting_hat" milestone:
                create one
            if there is no "did_not_finish" label:
                create one
            for every open ticket in the milestone that just closed:
                move it to the sorting_hat milestone
                if it does not have the "did_not_finish" label applied:
                    apply it

and

when an milestone closes on a repo with autosprint:
    chose the open milestone with the most-recent completion date as "current milestone":
        if there is no project board with the same name as the current milestone:
            create one
            for every ticket in the current milestone:
                if it is not on the current_milestone project board:
                    add it to the current_milestone project board (backlog column)
monkeypants commented 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.

ltankey commented 6 years ago

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"

ltankey commented 6 years ago

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".