Repository navigation
New folder structure for Patterns #154
Description
I propose a folder structure that reflects the maturity that a given pattern as reached.
Specific proposal:
patterns
├── donut
├── proven
└── unproven
What happens to the existing patterns:
- We would move all existing patterns into the respective subfolder.
- We would also keep the "Status" field in the pattern file itself.
Why is this useful? (purpose)
- easier to autogenerate an ebook of only the proven patterns (i.e. all files in new folder
patterns/proven - ability to merge PRs more quickly, even if they are not fully reviewed (see conversation in Slack) - also see Questions below
- clears up the root directory of the GitHub repo, leading to a clear separation between patterns and other meta data files that we only need for managing the repo, or for the book generation etc
- opportunity for further automation - e.g. autogenerate an index page of all patterns and their patlet, similar to what we have in the main
README.mdtoday.
Concerns
- We have some open PRs that work on edits to the existing patterns. Changing the folder structure now would lead to merge conflicts. I suspect all PRs would have to rebase to master. Also whenever we merge those PRs in, we would always have to make sure that the patterns end up in the correct folder.
Questions
- in addition to the existing Pattern Maturity, there seems to be the desire to flag any pattern as Draft, indicating that it has not been fully reviewed by anybody. This should allow us to merge faster. => I get confused by this, as there then are two different taxonomies: One indicating how proven a pattern is, and one indicating the level of review that a pattern has experienced.
Activity
NewMexicoKid commentedon Apr 26, 2020
There are indeed (at least) two separate dimensions for assessing a pattern:
Is there a way to avoid the rebasing problem by putting in a clear metadata field in the pattern with the proven/unproven tag? Then auto-generation of an e-book can still be done without causing rebasing problems for outstanding PRs.
maxcapraro commentedon Apr 26, 2020
I feel we overly simplify if we treat the validation status as binary (proven, unproven).
My suggestion (see #155) would be: Use maturity levels as the primary dimension to process and edit the patterns and funnel them towards the e-book.
maxcapraro commentedon Apr 26, 2020
On topic: I think moving the patterns /contributions lifecycle to the folder structure is a good thing :)
lenucksi commentedon Apr 29, 2020
Regarding the rebasing problem:
spier commentedon Apr 29, 2020
Ok. We can wait for a couple of more PRs to be merged.
However I doubt that we will ever can to a clean slate (i.e. 0 PRs), so sooner or later we will have to deal with a couple of merge conflicts when introducing this patterns folder structure.
But anyhow, I am happy to wait with this for a bit longer.
lenucksi commentedon Apr 30, 2020
If we can reduce this to ~5 PRs having to be rebased / merged / ... that would already be a bit nicer than having to do this for ~20 PRs.
spier commentedon Apr 30, 2020
Makes sense. Let's try :)
spier commentedon May 7, 2020
@lenucksi I got curious which of the open PRs are introducing new patterns vs how many are modifying existing ones. My assumption is that we would only see merge conflicts for modifications.
tl;dr
I went through all open PRS and classified them. Only #63, #101 and #102 represent changes to existing patterns. So if we could get them merged or closed, then all other PRs are just new patterns that won't lead to merge conflicts.
Details
2019
2018
2017
spier commentedon Dec 25, 2020
We didn't end up with the folder structure originally proposed in this issue, but rather one that follows the new maturity levels:
Still we can close this issue as the purposes that this issue was after has been achieved 🎈