Establish pattern system - #80
Conversation
rrrutledge
left a comment
There was a problem hiding this comment.
This looks like a good starting point, especially leading up to Friday's call. Can anyone else approve also? I think that one other approval feels like sufficient to merge. It would be nice to make PRs against this file in master.
Added Iba's paper as a reference on building pattern languages; and also proposed another plane for classifying InnerSource patterns.
|
I agree that this is a great starting point, thanks for thinking of this problem @gruetter ! However it comes to my mind other characterization and this is based on Jim's talk "InnerSource 101 and The Apache Way"[1]: Culture, Communication, Transparency, Collaboration, Community and Meritocracy as the main points to characterize all of the patterns. I see the one proposed by @gruetter focused on the process when adopting InnerSource and I like that as well (please correct me if I'm wrong!! U_U ). I would perhaps more generic steps such as: pre-adoption, early adoption, etc... And then it comes to my mind as third option the way to internally sell InnerSource within an organization and this basically implies all of the departments in that organization that a given pattern can affect. For instance, the 'Review Committee' pattern helps with the process of letting developers work on their own and still give control to middle management and business roles. Would it make sense to have another potential characterization based on the companies structure? I foresee areas such as: DevTeams, Marketing, Management, Legal, Business, Financial, etc... [1] https://es.slideshare.net/jimjag/apachecon-2017-innersource-and-the-apache-way |
|
@rrrutledge , |
|
Wow. Excellent contributions, @dicortazar and @NewMexicoKid . Looking forward to tomorrows discussion. |
|
|
||
| ### Georg Grütter | ||
|
|
||
| I propose we use a classification of the problem, a pattern tries to solve as |
There was a problem hiding this comment.
I think a agree with this sentiment but would like to propose that "the problem" be defined as the intersection of vectors in any number of the planes that we're listing out below.
No problem! My main motivation was to have a place where we could iterate and give more content but it looks like we are just doing that here in this branch! |
|
When we first discussed this I thought more about the different activities / implication one needs to address when implementing inner source rather than the adoption stages. But both are very useful and helpful. If we adopt tags, we can have multiple vectors of classifications at once. For example one pattern can be tagged for #mid-management-buy-in and on the same time #Getting-started-with-InnerSource. Or even one pattern can be applied to different stages of adoption.
|
rshanmer
left a comment
There was a problem hiding this comment.
The classifications that resonated most with me are Georg's (Getting started, middle mgmt, dev buy-in, fostering contributions, and interfacing). at my first thought these are helpful as I'm starting a program of inner sourcing.
However -- who's our intended audience for the patterns? is it someone just getting started or people in the thick of doing things that want extra help with tools or product development or innovation (e.g. Tim's list)?
... I still like Georg's.
To add to what Tim wrote -- the GOF book is a collection of patterns. I agree that we want to create a language (it's cooler and ultimately more useful). But my experience suggests that we're better off building a catalog first, then reflecting on the catalog and seeing what gaps there are in a language that we need to fill in and then address them to make a language. My $.02 is that we should keep the idea of a language in the back of our minds and just try to cover the terrain with a rough map that we can fill in between. When do we start filling in? Once we are pretty confident that we have basic topography covered (or started) in each of our classification areas.
- added categorizations for Tims and Georgs proposal based on discussion in 2017-12-01 patterns group meeting
NewMexicoKid
left a comment
There was a problem hiding this comment.
Looks okay to be one of our published documents; went ahead and merged this. We can later edit this and/or augment it with other documents.
|
Woah, for something so old I think it would have been good to wait a bit and bring up the topic again with folks. Was something else dependent on this pull getting merged? |
|
No, no dependencies. Just thought it was safe to merge (and reduce our open PR count). |
Hi everyone. I have prepared a document to collect and discuss ideas for a pattern system for the InnerSource patterns in preparation for the Dec. 1st patterns group meeting. It includes a summary of related work on patterns in the software space and a proposal for organising our patterns.
I'd like to invite you to add your own proposals and to provide feedback for other proposals in the PR.