Finalize PM Workflow for Specs

[DavidLiedle]

Perhaps you've noticed that this repository is empty... we know! We are getting things set up to share requirements and specifications here "in the wild" on GitHub in this repo, so you'll see lots of action here soon.

[DavidLiedle]

PM team -- let's meet to discuss. :)

[DavidLiedle]

The concept of themes as explored in #15 is interesting, and something we should discuss further. I think it speaks to the need for clarity on what is an Epic, a Milestone, a Story, a Task, and an issue-in-general, and could be one growing pain exploring GitHub Projects vs JIRA. I like the directness of it, but wonder if perhaps it is not simply implicit when using Labels more than once across different issues. Themes form organically under those conditions, and save a lot of redundancy between the title and the Label's self-identification as an instance of a Theme. Like Twitter hashtags, the notion of a theme exists the minute more than one thing has the same label applied.

[DavidLiedle]

Folders for stages is another thing to explore. At the PM meeting on GitHub workflow for specs (which we have to continue - got cut short on Thursday), we discussed perhaps using branches for draft, approved, etc.

[andrerom]

Folders: from my side I was thinking we would use projects to track progress, but merges to master being done without any discussion meant we would need to add folders. But if we don't do that, we can solve it w/o folders.

[DavidLiedle]

We won't ever merge to master without any discussion - always a PR, whether originating from a fork or from a branch. The question is, do we then do that merge to a "draft" branch, or make sure the draft is in a "draft" folder? To me, the branch approach makes the most sense.

[andrerom]

Well it wouldn't be a draft branch, it would then rather be a feature branch as one spec has different life cycle then others.

[bdunogier]

I agree with @andrerom. A draft branch does not work, I think: the point of a branch is to be merged. If we have 3 specifications in draft, we most likely don't want to merge the 3 specs at the same time.

The folders approach is I think a good one, and matches the doc/specifications folder structure we have in kernel. When a spec is meant to move from draft to confirmed or something, it is as simple as issueing a PR that moves the file, and have it approved.

[DavidLiedle]

Thanks for your input, all! The PM team met day-before-yesterday to nail down how we'll operate internally, and as of Feb 1 we have a structure in place that we think will work well.