You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would suggest to use GitFlow with the following branches:
master-public - branch containing publicly released patterns
master-private - branch containing internal released patterns
develop
The workflow could look like:
Write down the pattern idea as an issue and label it (donut, etc.)
create a feature branch (source would be develop) and add the pattern
open PR (target would be develop) and let the pattern been reviewed (unofficial small review 4 eyes principle) and merge
create a release branch (source would be master-public - for patterns which should be released out into the open - or master-private - for patterns which we want to keep inside of the patterns community) and finish the pattern
open PR (target would be master-public or master-private) and perform a review by the InnerSource Patterns Community and merge
add tag for the released stuff, could be something like donut-1.0 or draft-1.0 etc.
publish patterns on innersourcecommons.org - I would use the GitHub pages to store the patterns directly on the InnerSource webpage
optional: create and maintain a wiki page which includes all released patterns with version numbers, links and status
We could use your repo @gruetter to try that out. What do you think?
Thanks for starting this, @HaRo87 ! I'm thinking that we can simplify this. I was thinking to follow this approach:
We're not doing releases, so I propose to omit the separate develop and master branches and only use master.
Every pattern idea, donut or draft should start on a dedicated branch, originating from master. I propose to use the branch prefix newPattern.
Once a pattern idea/donut/draft is ready for review, authors should start a PR and label it with either Donut, Idea or Pattern and also with Ready for Review. Author should notify reviewers and invite comments.
tbd: review process - we should try this together @HaRo87 and figure out how to use GitHubs mechanisms for performing the review - not too familiar just yet.
once a pattern was accepted by the reviewers, it should be labeled Accepted and merged to master. It should also be published on the innersourcecommons.org. We could think about applying a dedicated label for that (e. g. published)
So in summary, all ongoing work on patterns should be on newPattern/ branches. Once a pattern is on master, it is viewed as accepted and published. I'm not sure we should use the issue tracker, actually. If we do everything via PRs, that might just be enough. We could use issues solely to track meta stuff such as suggestions, questions and the like.
I really like your simplified approach @gruetter! Let's try this out.
once a pattern was accepted by the reviewers, it should be labeled Accepted and merged to master. It should also be published on the innersourcecommons.org. We could think about applying a dedicated label for that (e. g. published)
What about patterns which should not be published on innersourcecommons.org, how should we handle them?
I'm not sure we should actually use the issue tracker, actually. If we do everything via PRs, that might just be enough. We could use issues solely to track meta stuff such as suggestions, questions and the like.
I would use the issue tracker for tracking pattern ideas as well. That would help to keep an eye on all the ideas, which I think are more than patterns we will write. It also helps to get new interested contributors on board.
What about patterns which should not be published on innersourcecommons.org, how should we handle them?
Hmm. Are you thinking ideas which didn't work out? If a pattern is merged to master, I assume they would also be published. Anonymous patterns would also be possible. If a pattern should not be published, I'd rather put it in a folder so that it is available for review for all branches which originate from master after that.
I would use the issue tracker for tracking pattern ideas as well. That would help to keep an eye on all the ideas, which I think are more than patterns we will write. It also helps to get new interested contributors on board.
Hmm. Are you thinking ideas which didn't work out? If a pattern is merged to master, I assume they would also be published. Anonymous patterns would also be possible. If a pattern should not be published, I'd rather put it in a folder so that it is available for review for all branches which originate from master after that.
I was thinking about patterns which should not be published - could be that the author does not have the rights to do that.
Instead of using folders we could also use labels.
Should we also think about defining categories for the patterns? Could help to have a good structure.
Labels can only be applied to PRs and issues, AFAIK. If someone clones the repo, I would like him to see the accepted patterns and those, who have been discarded, too. That's why I proposed to use folders instead of labels.
As for categories, I think donut, idea and pattern would be a good start. Still not sure if we should group patterns of one category in dedicated folders. Moving them between folders would break links. Using file prefixes to indicate the type is also not super nice and would have the same problem if we change the category.
Activity
HaRo87 commentedon Nov 18, 2016
Here is a first idea:
I would suggest to use GitFlow with the following branches:
The workflow could look like:
develop) and add the patterndevelop) and let the pattern been reviewed (unofficial small review 4 eyes principle) and mergemaster-public- for patterns which should be released out into the open - ormaster-private- for patterns which we want to keep inside of the patterns community) and finish the patternmaster-publicormaster-private) and perform a review by the InnerSource Patterns Community and mergedonut-1.0ordraft-1.0etc.We could use your repo @gruetter to try that out. What do you think?
gruetter commentedon Nov 18, 2016
Thanks for starting this, @HaRo87 ! I'm thinking that we can simplify this. I was thinking to follow this approach:
developandmasterbranches and only usemaster.master. I propose to use the branch prefixnewPattern.master. It should also be published on the innersourcecommons.org. We could think about applying a dedicated label for that (e. g. published)So in summary, all ongoing work on patterns should be on
newPattern/branches. Once a pattern is onmaster, it is viewed as accepted and published. I'm not sure we should use the issue tracker, actually. If we do everything via PRs, that might just be enough. We could use issues solely to track meta stuff such as suggestions, questions and the like.What d'ya think?
HaRo87 commentedon Nov 18, 2016
I really like your simplified approach @gruetter! Let's try this out.
What about patterns which should not be published on innersourcecommons.org, how should we handle them?
I would use the issue tracker for tracking pattern ideas as well. That would help to keep an eye on all the ideas, which I think are more than patterns we will write. It also helps to get new interested contributors on board.
gruetter commentedon Nov 18, 2016
Hmm. Are you thinking ideas which didn't work out? If a pattern is merged to master, I assume they would also be published. Anonymous patterns would also be possible. If a pattern should not be published, I'd rather put it in a folder so that it is available for review for all branches which originate from
masterafter that.Good points. Let's do it like this, then.
HaRo87 commentedon Nov 18, 2016
I was thinking about patterns which should not be published - could be that the author does not have the rights to do that.
Instead of using folders we could also use labels.
Should we also think about defining categories for the patterns? Could help to have a good structure.
gruetter commentedon Nov 18, 2016
Labels can only be applied to PRs and issues, AFAIK. If someone clones the repo, I would like him to see the accepted patterns and those, who have been discarded, too. That's why I proposed to use folders instead of labels.
As for categories, I think donut, idea and pattern would be a good start. Still not sure if we should group patterns of one category in dedicated folders. Moving them between folders would break links. Using file prefixes to indicate the type is also not super nice and would have the same problem if we change the category.
HaRo87 commentedon Nov 18, 2016
The labels are only visible inside of the PR @gruetter. Do we need them after merge?
#5 InnerSource Patterns workflow
refined workflow #5
added branching instruction (accidentally removed in previous commit) #5
added ideas from Georg #5
Merge Workflow description
GitBook: [#5] No subject