[neomutt-devel] Issue labels / Waffle Board
Pietro Cerutti
gahr at FreeBSD.org
Tue Jan 31 08:51:37 CET 2017
On 31 Jan 2017, at 00:48, Richard Russon <rich at flatcap.org> wrote:
>> 1) In my experience, issues are better left open until the code fixing
>> them is released.
>
> I'd like that too, but I can't seem to fit it into the tools.
> It would mean that we'd need an extra waffle column and the "Done" wouldn't be used.
>
>> having them in an open state ... reduces the likeliness of duplicates.
>
> Given the short development cycles that we have,
> I'm willing to accept that sometimes we might get a duplicate issue.
>
>> It also gives a general idea of what's going to go into the next release.
>
> Hopefully, the milestone "next-release" should show this info.
>
>> I don't see a reason for having a
>> separate status between approval and merging.
>
> I agree. I propose:
> (bug and discussion omitted for clarity)
>
> [pool] - unsorted issues
> [status:backlog] - selected for this release
> [status:in-progress] - works in progress
> [status:review] - waiting for review
> [done] - merged into master
>
> Issues selected for the next release
>
> [pool] -> [backlog] (moved by Reviewer)
>
> Developer starts work on issue.
> They assign themself to the issue.
>
> [backlog] -> [in-progress] (moved by wafflebot, or Reviewer)
>
> Developer wants feedback
> Creates Pull-Request, asks for comments
>
> [in-progress] (no change)
>
> Developer finishes work.
> Asks for review (@neomutt/reviewers)
>
> [in-progress] -> [review] (moved by Reviewer)
>
> Reviewer finds a problem with the code
> (unless trivial)
>
> [review] -> [in-progress] (moved by Reviewer)
>
> First Reviewer approves the code (github approval)
>
> [review] (no change)
>
> Second Reviewer approves the code (github approval)
> Merges the code
>
> [review] -> [done] (moved by wafflebot on closing)
>
LGTM :)
--
Pietro Cerutti
gahr at gahr.ch
More information about the neomutt-devel
mailing list