ChiliProject.org Issue Workflow and Statuses (Task #84)

I propose:

• New - Issues start here. Means that an issue has been proposed.
• In Progress - Someone is working on the issue.
• Ready for merge to master - The issue has been fixed in a branch and is ready for merging to master.
• Ready for merge to stable - The issue has been fixed in a branch and is ready for merging to stable.
• Closed - Issue is completed.

• Need more information - The issue needs more information before it can be worked on.
• Declined - Issue will not be done for a reason.
• Duplicate - Issue is a duplicate of another issues.

The basic process would be New => In Progress => Ready for merge to master [1] => Ready for merge to stable [2] => Closed

[1] - this is assuming that the code is ready in a developer's branch and isn't in the project repository yet (e.g. pull requests)
[2] - this is assuming that the code will be merged into the stable branch and depends on the changes and release.

The other status are "exception" statuses that are outside the normal flow.

Holger:

I like "Open" as the starting status. And your simple Task and Documentation workflow might be good.

• Do we want a Support tracker or should that be in the Forums?
• Do we want to add a Documentation tracker or category? I'm thinking category because it might be code docs that need to be merged and (rest of the workflow for code).

Eric Davis wrote:

• Do we want a Support tracker or should that be in the Forums?

I'd like Felix to chime in on this one, as he does way more support on the site than the rest of us.

• Do we want to add a Documentation tracker or category? I'm thinking category because it might be code docs that need to be merged and (rest of the workflow for code).

I think a category will be more than sufficient.

Talked with Holger and tried to simplify the workflow:

• Open - Issues start here. Means that an issue has been proposed.
  • Open with an assignee - Someone is working on the issue.
• Ready for review - The issue has been fixed in a branch and is ready to be reviewed for committing to the project's repository
• Closed - Issue is completed in the project's repository.
  • Should include master but could also include a stable branch
  • Should set the release version: only merged to master => next major release. Merged to master and stable => next minor release.

Exception statuses:

• Need more information - The issue needs more information before it can be worked on.
• Declined - Issue will not be done for a reason.
• Duplicate - Issue is a duplicate of another issues.

The basic process would be Open => Ready for Review => Closed.

More in depth example showing the standard process for a non-committer (1-2), a committer review (3-6), adding code to master (5), and reverting a mistake (7-9)

15:35 < edavis10> (Call the non committer Bill)
15:35 < edavis10> 1. Bill pushes to his repo on github
15:35 < edavis10> 2. Bill sets the issue status to Ready for review and posts his repo's name/url/branch
15:35 < edavis10> 3. Eric reviews Bills code and thinks it's good
15:35 < edavis10> 4. Eric merges/cherry-picks Bills code into master
15:36 < edavis10> 5. Eric thinks the code is good for stable so he cherry-picks the code that was committed to master and puts it into stable
15:36 < edavis10> 6. Eric updates the issue: Closed status, Version => next minor release, Assigned to Eric
15:36 < edavis10> 7. Holger reviews the patch and thinks it shouldn't be in stable.
15:37 < edavis10> 8. Holger discusses... and reverts Eric's patch from 5
15:37 < edavis10> 9. Holger sets the issue's version to => next major release

Oh and as for the actual "workflow", I propose keeping it 100% open so people can set the status to anything except the current status. Makes it easier to manage:

Needs more info can go to => [Open, Ready for Review, Closed, Declined, Duplicate] etc

Muntek Singh wrote:

Eric Davis wrote:

• Do we want a Support tracker or should that be in the Forums?

I'd like Felix to chime in on this one, as he does way more support on the site than the rest of us.

I liked keeping code stuff/tracker separate from support stuff/forums, i.e. I don't want a support tracker and handle everything in the forums. If it gets to awkward/overwhelming/whatever, we can always change later.

• Do we want to add a Documentation tracker or category? I'm thinking category because it might be code docs that need to be merged and (rest of the workflow for code).

I think a category will be more than sufficient.

Category.

Eric Davis wrote:

Talked with Holger and tried to simplify the workflow:

• Open - Issues start here. Means that an issue has been proposed.
  • Open with an assignee - Someone is working on the issue.
• Ready for review - The issue has been fixed in a branch and is ready to be reviewed for committing to the project's repository
• Closed - Issue is completed in the project's repository.
  • Should include master but could also include a stable branch
  • Should set the release version: only merged to master => next major release. Merged to master and stable => next minor release.

Exception statuses:

• Need more information - The issue needs more information before it can be worked on.
• Declined - Issue will not be done for a reason.
• Duplicate - Issue is a duplicate of another issues.

The basic process would be Open => Ready for Review => Closed.

More in depth example showing the standard process for a non-committer (1-2), a committer review (3-6), adding code to master (5), and reverting a mistake (7-9)

15:35 < edavis10> (Call the non committer Bill)
15:35 < edavis10> 1. Bill pushes to his repo on github
15:35 < edavis10> 2. Bill sets the issue status to Ready for review and posts his repo's name/url/branch
15:35 < edavis10> 3. Eric reviews Bills code and thinks it's good
15:35 < edavis10> 4. Eric merges/cherry-picks Bills code into master
15:36 < edavis10> 5. Eric thinks the code is good for stable so he cherry-picks the code that was committed to master and puts it into stable
15:36 < edavis10> 6. Eric updates the issue: Closed status, Version => next minor release, Assigned to Eric
15:36 < edavis10> 7. Holger reviews the patch and thinks it shouldn't be in stable.
15:37 < edavis10> 8. Holger discusses... and reverts Eric's patch from 5
15:37 < edavis10> 9. Holger sets the issue's version to => next major release

Looks good to me, except that we might need an extra status for features (merged to major tip but not yet minor tip).

Looks good to me, any naysayers?

• master for bug-fixes and compatible features
• unstable for features

So I'm fine here.

Ok, I have Open, Ready for Review, Needs more information, Closed, Duplicate, Declined, the last 3 closing the issue. All those for the moment only for Committers, Moderators and non-members on bugs, everyone can go from any to any state except back to itself.

Speaking of trackers: Bugs, Features, what else?

• Bug - code doesn't work like it should
• Feature - code should work this new way
• Task - non-code change (e.g. website, internal stuff, documentation)

I'd remove Support, it should be handled in the forums.

Sounds good, will take care of it.

First of all: sorry for the status change noise, I had totally forgotten they could be renamed…

Changed the statuses and workflows thus: "Open, Ready for Review, Needs more information, Closed, Duplicate, Declined" for Bugs and Features, "Open, In Progress, Closed, Declined" for Tasks. I think the later benefits from having at least "In Progress" to signalize that someone's taking care of it, even if we do it through the assigned to for the other 2 trackers?