InnerSource Patterns workflow #8

HaRo87 · 2016-11-19T13:30:08Z

here comes a first draft for the InnerSource workflow description. I think it would also make sense to invite the other pattern folks as well (Tim, Cedric, Padma, ...). Will do that on Slack.

- this fixes #5 - added first workflow description

gruetter

Done with the initial rework and review, @HaRo87 . Excellent start!

gruetter · 2016-11-19T20:07:49Z

workflow.md

+  * be labeled with the appropriate label (_idea_, _donut_, _pattern_) 
+# Create a new branch either in your clone or fork of the 
+  [patterns repository][patternsRepo]. Please use the following pattern for
+  naming branches: `pattern/<patternName>`. Example: 


I have removed the issue label from the branch name, @HaRo87 as GitHub does not apply the same auto linking as Bitbucket. AFAIK, only commits can be tagged with issue ids.

OK, makes sense to do that.

gruetter · 2016-11-19T20:08:49Z

workflow.md

+  naming branches: `pattern/<patternName>`. Example: 
+  `pattern/contractedContributor`.
+# Create a _Markdown_ file with the description of the _idea_, _donut_ or
+  _pattern_ and store it either the `ideas`, `donuts` or `patterns` 


added the subdirectories as a proposal. I think it would make sense to do this in order to avoid having a user of the repo guess whether a file describes an idea, a donut or a pattern.

I like the idea of putting the stuff into separate directories. Having a look at the Patterns template there are a couple of states a pattern can have:

brainstormed solution (not proven), a donut (no solution), a proven solution, a reviewed pattern, an untested idea, an unreviewed draft of a proven solution

Do we need to take that into account? Like having inside of each directory a folder proven?

Hmm. Here's an idea:

On a patterns branch, always start the pattern .md file in the main directory (by convention). That way, it is obvious what file is being worked on.

Once the review is complete and prior to merging the patterns branch, it should clear what the pattern is (idea, donut or pattern). So before merging, move the file to the appropriate subdirectory.

I've added your proposal with ea6acba @gruetter.

gruetter · 2016-11-19T20:09:59Z

workflow.md

+
+### Publishing a InnerSource pattern on innersourcecommons.org (InnerSourceCommons repository)
+
+* for each new pattern which should be published a new issue should be created


It was my understanding that we will publish the patterns on the wiki, once they are accepted in the patterns repo. Does this work with PRs, as well, @HaRo87 ?

What do you mean by:

Does this work with PRs, as well, @HaRo87 ?

I think a wiki is not the right place to publish patterns, or? In a wiki you can also edit and change stuff. On the GitHub pages site of InnerSource Commons a published pattern will have a stable (not so easy to change) state.

Does this work with PRs, as well, @HaRo87 ?

I was wondering whether it is possible to restrict wiki editing with PRs. I guess we can just as well store patterns as .md files and link to them from the wiki. I personally think a 2nd PR after the first would be a bit over the top ;)

OK, I think we have a communication issue here. ;-) I would use the GitHub pages site: innersourcecommons.org to publish the patterns, not the wiki.

HaRo87

Should we leave that PR open until some of the InnerSource Patterns folks will participate or should we close it once we're done and discuss our proposal in another way?

HaRo87 · 2016-11-19T13:37:53Z

workflow.md

+There are two separate repositories needed for this workflow:
+
+* [InnerSourceCommons](https://github.com/paypal/InnerSourceCommons)
+* InnerSourcePatterns [todo: create and add link to repo]


The patterns repo has to be created, right?

HaRo87 · 2016-11-19T13:38:47Z

workflow.md

+* once a pattern was accepted by the reviewers, it should be labeled `Accepted`
+and merged to `master`
+
+### Publishing a InnerSource pattern on innersourcecommons.org (InnerSourceCommons repository)


We have to define a place where we want to store the patterns on innersourcecommons.org.

HaRo87 · 2016-11-21T19:58:58Z

workflow.md

+  * be labeled with the appropriate label (_idea_, _donut_, _pattern_) 
+# Create a new branch either in your clone or fork of the 
+  [patterns repository][patternsRepo]. Please use the following pattern for
+  naming branches: `pattern/<patternName>`. Example: 


OK, makes sense to do that.

HaRo87 · 2016-11-21T20:03:14Z

workflow.md

+  naming branches: `pattern/<patternName>`. Example: 
+  `pattern/contractedContributor`.
+# Create a _Markdown_ file with the description of the _idea_, _donut_ or
+  _pattern_ and store it either the `ideas`, `donuts` or `patterns` 


I like the idea of putting the stuff into separate directories. Having a look at the Patterns template there are a couple of states a pattern can have:

brainstormed solution (not proven), a donut (no solution), a proven solution, a reviewed pattern, an untested idea, an unreviewed draft of a proven solution

Do we need to take that into account? Like having inside of each directory a folder proven?

HaRo87 · 2016-11-21T20:05:18Z

workflow.md

+
+### Publishing a InnerSource pattern on innersourcecommons.org (InnerSourceCommons repository)
+
+* for each new pattern which should be published a new issue should be created


What do you mean by:

Does this work with PRs, as well, @HaRo87 ?

I think a wiki is not the right place to publish patterns, or? In a wiki you can also edit and change stuff. On the GitHub pages site of InnerSource Commons a published pattern will have a stable (not so easy to change) state.

HaRo87 · 2016-11-23T06:25:15Z

Should we leave that PR open until some of the InnerSource Patterns folks will participate or should we close it once we're done and discuss our proposal in another way @gruetter?

nyeates · 2016-12-05T22:32:46Z

This PR needs to be accepted sooner than later if we are going to continue to work forward here. I assume the "Test" monicker will soon be removed from the name of this repo. There needs to be instructions like this in the root of the repo - actually they would be more visible in the README, but let's at least get a draft version out there of this. There can be additional pull requests for further changes.

NewMexicoKid · 2016-12-05T22:43:51Z

Nick, re your comment "I assume the "Test" monicker will soon be removed from the name of this repo." -- do note that this is just a test repo; the content of this workflow will need to be copied over to the real repository that Cedric set up.
That being said, I agree that the pull request should be accepted.

nyeates · 2016-12-06T04:11:36Z

It might be worth considering to simply fork or replicate this repo over at InnerSourceCommons (or wherever). Otherwise, the many valuable comments, already numerous commit history (from many parties - which is a very positive thing to keep track of), and issues will be erased. Why start from zero when we have a good thing going here? Maybe there is something I don't understand though... do explain if so.

This is not the best place to put this kind of suggestion - I'll be sure to mention it elsewhere.

* Added the translation of communication-tool * Updated the translation with review comments

HaRo87 and others added 3 commits November 19, 2016 14:26

#5 InnerSource Patterns workflow

8ae027a

- this fixes #5 - added first workflow description

refined workflow #5

c9316c3

added branching instruction (accidentally removed in previous commit) #5

0ba2608

gruetter reviewed Nov 19, 2016

View reviewed changes

HaRo87 commented Nov 21, 2016

View reviewed changes

added ideas from Georg #5

ea6acba

nyeates merged commit 33092a0 into master Dec 15, 2016

nyeates deleted the feature/#5-InnerSource-Workflow branch December 15, 2016 08:47

spier pushed a commit that referenced this pull request Dec 29, 2022

Added the translation of communication-tool (#8)

06254c4

* Added the translation of communication-tool * Updated the translation with review comments


		### Publishing a InnerSource pattern on innersourcecommons.org (InnerSourceCommons repository)

		* for each new pattern which should be published a new issue should be created

InnerSource Patterns workflow #8

InnerSource Patterns workflow #8

Uh oh!

Conversation

HaRo87 commented Nov 19, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gruetter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gruetter Nov 22, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gruetter Nov 22, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HaRo87 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

HaRo87 commented Nov 23, 2016

Uh oh!

nyeates commented Dec 5, 2016

Uh oh!

NewMexicoKid commented Dec 5, 2016

Uh oh!

nyeates commented Dec 6, 2016

Uh oh!

Uh oh!

HaRo87 commented Nov 19, 2016 •

edited

Loading

gruetter Nov 22, 2016 •

edited

Loading

gruetter Nov 22, 2016 •

edited

Loading