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

pattern/junkyard-styled-innersourcing #61

Merged
merged 2 commits into from Sep 25, 2017

Conversation

Projects
None yet
5 participants
@nyeates
Collaborator

nyeates commented Mar 11, 2017

People don't share something so others can use it; they only share it for the sake of sharing. They wouldn't mind if no one uses it (a bit of a graveyard: "InnerSource is where modules go to die")

Created
This is also in master, and it really shouldn't be, as its not a mature pattern at all. Starting a PR to start a proper Review Process.
@rshanmer

This comment has been minimized.

Collaborator

rshanmer commented Apr 5, 2017

A bunch of thoughts:

  • Since this is a donut, it might be best to start with one of the two situations in the context and focus on it.
  • When I read this problem statement I think about the person that likes to share their code -- that likes others to read it (and maybe comment on it). But mostly they like to write code. "Hey, I wrote this nifty gzorp and you might like it (but its no skin off my nose if you don't)"
  • Is that really context and the problem is: "How do you encourage people to share whatever code they write?"
  • Then some forces might be: * the code is crap, * the code doesn't address any of the company's problems (at the moment anyway), * How does the person let others know that the code exists?, * We want the person to contribute code, so what roadblocks need to be removed so that they continue making their code available?, * How do we politely take their freely offered code and harden it or otherwise prepare it for production without having the original contributor feel like we are saying their code is crap?
  • Possible solution: Support all contributions to the shared repository.
  • Resulting context: Provide some sort of grading (Alexander marked his patterns with 0, 1 or 2 stars depending upon how convinced he was that it was a good pattern), so that the reader can be aware of what to expect. But how to do that without insulting the contributor? (soln: engage them in the process -- have 2 scores, what they think, and what users think or how many times its been used)

@nyeates nyeates requested a review from rshanmer Apr 21, 2017

* SW component not designed for reuse because the schedule was too tight and did not allow for the extra effort needed
* Did not have the knowledge or training to create components that can b reused.

This comment has been minimized.

@rshanmer

rshanmer Apr 21, 2017

Collaborator

See other suggestion to pick one context. [test]

Update junkyard-styled-innersourcing.md
Merging in comments to this point except for the one to split this into two patterns based on the two situations listed in the context.
@rshanmer

This comment has been minimized.

Collaborator

rshanmer commented Sep 25, 2017

Merged before workshop at Fall Summit.

## Context
Two situations:
* SW component not designed for reuse because the schedule was too tight and did not allow for the extra effort needed

This comment has been minimized.

@gruetter

gruetter Sep 26, 2017

Collaborator

I would argue that the effort for designing SW for reuse should only be spent, if it is crystal clear that it in fact will be reused. Otherwise, YAGNI applies. So either it was clear that it would be reused and it wasn't designed that way for the reasons you mentioned, or it wasn't clear and therefore not designed for reuse (and rightly so).

* Did not have the knowledge or training to create components that can b reused.
## Problem
* How do you encourage people to share whatever code they write?

This comment has been minimized.

@gruetter

gruetter Sep 26, 2017

Collaborator

Hmm, the pattern title suggests to me that people are sharing, just not stuff that is ready to be reused. How about we rephrase the problem statement to s.th. like Shared code is not reused because it was not written with reuse in mind or is not reusable.

* A developer might be a person who likes to share their code; one that likes others to read it (and maybe comment on it. But mostly they like to write code. "Hey, I wrote this nifty gzorp and you might like it (but its no skin off my nose if you don't)"
* the code is crap
* the code doesn't address any of the company's problems (at the moment anyway)
* How does the person let others know that the code exists?

This comment has been minimized.

@gruetter

gruetter Sep 26, 2017

Collaborator

I was wondering if this is a force ... as an idea: The less effort is spent on publicising shared code the less likely it is that it will be found and reused.

## Problem
* How do you encourage people to share whatever code they write?
## Forces

This comment has been minimized.

@gruetter

gruetter Sep 26, 2017

Collaborator

@rshanmer : Some of the forces in this pattern are formulated as questions, rather than e. g. tradeoffs. Is this a valid way to phrase forces?

* How do we politely take their freely offered code and harden it or otherwise prepare it for production without having the original contributor feel like we are saying their code is crap?
## Solution
* Support all contributions to the shared repository.

This comment has been minimized.

@gruetter

gruetter Sep 26, 2017

Collaborator

I like the idea behind this but I feel this needs to be fleshed out a little. Here are some ideas:

  • Support the users in writing proper readme.md and contribute.md files, e. g. by providing templates
  • Announce new shared repositories in a weekly/monthly blog post and give the authors a chance to make themselves and their SW known to others
* How does the person let others know that the code exists?
* We want the person to contribute code, so what roadblocks need to be removed so that they continue making their code available?
* How do we politely take their freely offered code and harden it or otherwise prepare it for production without having the original contributor feel like we are saying their code is crap?

This comment has been minimized.

@gruetter

gruetter Sep 26, 2017

Collaborator

Suggestion for additional force: The more responsive the original author is to requests for changes coming from potential re-users of her code, the more likely it is that it will be reused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment