-
Notifications
You must be signed in to change notification settings - Fork 195
Move patterns to new folders #188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move patterns to new folders #188
Conversation
Small readability updates.
…)' to 'patterns/2-structured'
I am not sure what to do with these two categories from the README
Shared properties of most of these:
|
… 'patterns/2-structured'. While doing this I also moved the pattern trusted-committer.md out of the sub-folder 'project-roles'. There was only a single file in that folder anyways, and I suspect the folder might have been in place to prevent naming confusings with the file in the root TRUSTED-COMMITTERS.md. Given that the pattern file lives at 'patterns/2-structured/trusted-committer.md' now, that naming confusion should be no problem anymore.
I think that this logic would work to move the patterns to the new maturity model (and folder structure): Reviewed Patterns (proven and reviewed) | 11 patterns => 2-structured
Reviewed Pattern Ideas (not yet proven but reviewed) | 2 patterns => 1-initial
Pattern Drafts (proven, not yet fully reviewed) | 11 patterns => 2-structured
Pattern Ideas (not yet proven; brainstormed) | 7 patterns => 1-initial
Pattern Donuts (needing a solution) | 7 patterns/donuts => 1-initial
|
…)' to 'patterns/1-initial'. This fixes a previous move that was made in b4862ab
…iewed)' to 'patterns/2-structured'. I also noticed that the pattern 'Issue tracker use cases' was not linked from the main README, and decided to add it to the same block as well.
…t reviewed)' to 'patterns/1-initial'.
While this PR still has some outstanding tasks (see checklist above), it is already ready for a first review. @maxcapraro The description in #188 (comment) outlines the implementation path that I chose. If you could review that and confirm that it matches the idea that you had with the maturity levels, that would be awesome! |
I like the checklist that lays out the plan. Mapping previous 5 level of maturity to 3 would simplify the experience on the user side. However the current changes show all patterns got downgraded due to lack of known instances. Wonder whether that's a WIP in this PR or intended to be merged to main. What're your thoughts on finding instances for structured & proven patterns? Here's an idea for your consideration. How about showing the mindmap of patterns to the general slack channel and soliciting input there? Maybe they can follow the link in mindmap to the pattern md and open a PR to add their instance, or link to a talk that mentioned the pattern? |
Thanks for the feedback!
You are right, all patterns appear to get downgraded as part of this migration.
I have not really thought about that part that much I must admit. Been going step by step here 👍 Also if you want to give that approach a shot already, please do! I will try to get this PR here merged in the next week, so that we have the foundation for the new maturity levels in master. |
Small readability updates
Just updated issue with the idea. I will try to join the office hour next Thursday to discuss the plan more with you guys. For the ebook, maybe we can lay out a mindmap that lists all the major things for IS to think through, then ensure we can have all those major things covered with patterns? The upcoming summit would be a good time to solicit feedback & new patterns. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think those changes are excellent (particularly the sorting into the maturity levels).
One thing that I feel is important is that we drop the remains of the old process (terms like proven, categories that were used prior to the new approach). I proposed some inline changes for that.
In particular, I'd not distinguish whether something was review or not - because this is just a meta status to me. We can of course point readers to stuff that's not yet reviewed. But technically if a pattern hasn't been reviewed, it is not existing. In the same way, I think we should avoid the term proven. Entities that hold validity for a certain context only, cannot be proven :)
Except for this one thing that we all should discuss, I find the changes very good, though, @spier! And clearly a lot of good work went into this 👍
Co-authored-by: Maximilian Capraro <[email protected]>
Co-authored-by: Maximilian Capraro <[email protected]>
Co-authored-by: Maximilian Capraro <[email protected]>
Thanks for the feedback @maxcapraro .
I understand your line of thinking. Yes, eventually we should get rid of the remains of the old process completely, I 100% agree. My thought was to keep these sub-groupings below the maturity levels only for the time being, until we have completed the clean-up. It might be handy to still know these old groups and pattern states, so that we know what the next follow-up action for the clean-up should be. What do you think? I would like to find a solution PR quickly, as it blocks the further clean-up work, and new PRs that are opened now would also run into merge conflicts with this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be handy to still know these old groups and pattern states, so that we know what the next follow-up action for the clean-up should be.
I think you might be right! Keeping that information for now might make it easier for us.
Excellent. Accordingly I have resolved the remaining open suggestions without making any changes. @lenucksi if you could take a look and rebase on master to fix the conflict with Once that is done then i can do the "Notify PR authors" of the new maturity levels for the patterns that they are working on. |
@lenucksi I won't get to the remaining non-coding work in the checklist at the very top until early September. However if this PR looks good to you feel free to rebase and merge, as it will reduce the merge conflicts for new PRs. I can then do the remaining communication work (with the authors of open PRs) in early September. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing these changes @spier, as well as the review and discussion @maxcapraro and @fwan2000, also the good idea around collecting more confirmed instances @fwan2000.
I'm happy to merge this, however I can not do any rebasing work against your repo @spier since I miss the rights to do so.
I could either pull in your branch into the main repo and merge using a new PR, get rights on your branch or we wait until you've got time to do the rebase yourself.
Happy to reach out to PR authors as well. We should do as much of this on the public channels anyway.
Ah, right. I read the warning from GitHub the wrong way then. It said:
Hence I figured that one of the trusted committers to this repo has to do it. But if I can solve this on my own fork, I am more than happy to. Will try that now. |
…)' to 'patterns/2-structured'
… 'patterns/2-structured'. While doing this I also moved the pattern trusted-committer.md out of the sub-folder 'project-roles'. There was only a single file in that folder anyways, and I suspect the folder might have been in place to prevent naming confusings with the file in the root TRUSTED-COMMITTERS.md. Given that the pattern file lives at 'patterns/2-structured/trusted-committer.md' now, that naming confusion should be no problem anymore.
…)' to 'patterns/1-initial'. This fixes a previous move that was made in b4862ab
…iewed)' to 'patterns/2-structured'. I also noticed that the pattern 'Issue tracker use cases' was not linked from the main README, and decided to add it to the same block as well.
…t reviewed)' to 'patterns/1-initial'.
Co-authored-by: Maximilian Capraro <[email protected]>
Co-authored-by: Maximilian Capraro <[email protected]>
Co-authored-by: Maximilian Capraro <[email protected]>
…erSourcePatterns into move-to-initial-and-structured
@lenucksi this should be good to go now. |
The block |
I have notified all authors of open PRs in the group See for example: |
This is starting the work on #185.
I will keep a running checklist here until I am done.
Pattern Donuts (needing a solution)
topatterns/1-initial
Pattern Donuts
Pattern Ideas (not yet proven; brainstormed)
topatterns/1-initial
Pattern Ideas
Pattern Drafts (proven, not yet fully reviewed)
topatterns/2-structured
Pattern Drafts
Reviewed Pattern Ideas (not yet proven but reviewed)
topatterns/1-initial
(no PRs in this section)Reviewed Patterns (proven and reviewed)
topatterns/2-structured
(no PRs in this section)Notes
patterns/2-structured
Pattern Ideas (not yet proven; brainstormed)