pattern/common-requirements #11

nyeates · 2016-11-30T19:11:37Z

Common code in a shared repository isn't meeting the needs of all teams that want to use it. The team that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same.

This brings in the existing Pattern by Bob Hanmer, which was located here:
https://github.com/paypal/InnerSourceCommons/wiki/Common-Requirements

I did this wrong the first time, trying again, now with work done in a branch Info taken from existing wiki file at https://github.com/paypal/InnerSourceCommons/wiki/Common-Requirements

template, for now, is at https://github.com/paypal/InnerSourceCommons/wiki/InnerSource%20Patterns %20template

nyeates · 2016-11-30T19:14:07Z

Leaving this sit so that someone else can double check my work this time around @gruetter @HaRo87 ?

Context: I have volunteered to help bring over some of the patterns from the wiki to github. Let me know if I am doing it right this time!

gruetter · 2016-12-05T15:05:01Z

Looks good, @nyeates ! Thanks for kicking this off. I have added labels, assuming this pattern is ready for review.

nyeates · 2016-12-05T22:27:35Z

Curiosity question: why does the workflow instructions have you open both an issue and a PR for new patterns? Both have the same labels and similar information. It seems redundant. Why not just have PR's?

NewMexicoKid · 2016-12-05T22:54:16Z

For those of us with less experience on managing PRs, what is the common etiquette for merging the pull request? Who should feel responsible to check the status and to push the "Merge pull request" button? Is it a matter of availability to look at something and to make the decision? Or is there an unwritten rule on this?

Thanks for your advice.

gruetter · 2016-12-06T08:40:38Z

Why does the workflow instructions have you open both an issue and a PR for new patterns?

@nyeates : I agree that the way we are using the issue tracker now is somewhat redundant. @HaRo87 and I discussed this in the issue for the workflow creation and decided to keep issues to track ideas for patterns not yet written. I guess we can omit the issue if we already have content to be added to a PR.

gruetter · 2016-12-06T08:42:13Z

Who should feel responsible to check the status and to push the "Merge pull request" button?

@NewMexicoKid : In the projects I know, merging is restricted to trusted committers. Thus, they are the ones who need to check the status and merge. That's why we should have more than one TC, I think.

gruetter

Always good to learn from the master. Thanks Bob.

gruetter · 2016-12-07T12:33:29Z

common-requirements.md

+## Problem Statement
+The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.  
+
+## Forces


Are there any relevant forces related to the human factor in all this we should consider? For me personally, InnerSource is much more about culture and the human factor than it is about code and processes.

As a side note, one force that is human-related is that system engineers might tend to try to fill customer requirements locally within their own BL rather than reaching out to other BLs that support the same customer. Might be unrelated to this particular pattern, but this might be an InnerSource donut.

gruetter · 2016-12-07T12:38:54Z

common-requirements.md

+Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.  Decompose the code into smaller pieces for which the many using projects can agree upon requirements.  
+
+## Resulting Context
+This might require negotiating requirements changes with the customer.  It might also require other involvement by the sales teams and product managers to get alignment on the requirements.  


I would also mention the need to incentivize reuse and to make explicitly make a decision on the components scope (which requirements are in scope, which are not).

NewMexicoKid · 2016-12-07T15:54:48Z

common-requirements.md

+Statement of Problem:  The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.  
+
+## Problem Statement
+The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.  


Do we need to specify in the problem statement why the common code isn't meeting the needs? I.e., ... due to conflicting requirements from the participating projects.

gruetter · 2016-12-07T17:15:50Z

common-requirements.md

+
+## Context
+Many projects are trying to use common code.  There is a shared repository that all the projects access.  This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects.  Each project has its own delivery schedule, set of deliverables and customers.  
+Statement of Problem:  The common code in the shared repository isn’t meeting the needs of all the projects that want to use it.  


this line seems to be duplicated by line 9

gruetter · 2016-12-07T17:33:37Z

common-requirements.md

+Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.  Decompose the code into smaller pieces for which the many using projects can agree upon requirements.  
+
+## Resulting Context
+This might require negotiating requirements changes with the customer.  It might also require other involvement by the sales teams and product managers to get alignment on the requirements.  


Just as an idea: in the forces you mention that the customers sometimes expect the company to help them clarify their requirements. My idea is that this situation should be taken advantage of by bringing about the alignment during the customer requirements negotiations and change the customers requirements rather than changing the component.

nyeates · 2016-12-15T04:58:50Z

It took me a bit to fully understand this. After I read it the third time, I fully got it. A future revision could work on more up-front clarification.

Once I "got it", I do like it. The decomposing of requirements into smaller pieces sounds key to me. This point could be delved into deeper.

One concern I have is that many projects do not occur at the same time, sometimes even years apart. How can requirements be co-aligned amongst teams if the former team has moved on or simply not working on it much. I guess the new team then works to become the new code owners, all whilst aligning the requirements the best they can?

@gruetter

Added @gruetter idea on using customer requirements elucidation/negotiation

gruetter

Excellent pattern, Robert. I wish I could be as concise as this.

gruetter · 2017-02-08T12:46:58Z

common-requirements.md

+Reusing code is an important goal to save the company time and money.  
+
+## Solution
+Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.  Decompose the code into smaller pieces for which the many using projects can agree upon requirements.


I think it would help if we split this solution up into two separate bullet points: one for the requirements alignment, the other for the decomposition.

May I suggest to use a word other than Decompose? Even though that's what is done (technically), the important thing to me here is that we factor out/isolate code which varies across customers and create appropriate extension points.

gruetter · 2017-02-08T12:51:45Z

common-requirements.md

+Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.  Decompose the code into smaller pieces for which the many using projects can agree upon requirements.
+
+Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer negotiations and influence the customers requirements rather than changing the component.
+


From my old product line days I remember, that bringing about such an alignment requires an incentive for both the customers (usually price and TTM) and for the company itself. Should we mention this here or would that unduly bloat the pattern? Maybe this could go in the Resulting Context section, too.

This sounds like a reasonable thing to add to the pattern at this location.

That's a good comment for resulting context. It's a reflection that the problem (getting alignment) might introduce new problems (that require solutions like discounts).

rshanmer · 2017-08-31T20:06:34Z

Georg's comments included and the pattern updated to the PLoP 2017 draft.

* Added the translation of dedicated community leader * Fixed the lint error of dedicated-community-leader.md * Updated the translation with review comments

nyeates added 2 commits November 30, 2016 14:02

from Wiki try 2

3ee41c4

I did this wrong the first time, trying again, now with work done in a branch Info taken from existing wiki file at https://github.com/paypal/InnerSourceCommons/wiki/Common-Requirements

formatting to match template (try 2)

4c2c73e

template, for now, is at https://github.com/paypal/InnerSourceCommons/wiki/InnerSource%20Patterns %20template

gruetter added Pattern labels Dec 5, 2016

gruetter approved these changes Dec 7, 2016

View reviewed changes

NewMexicoKid reviewed Dec 7, 2016

View reviewed changes

gruetter reviewed Dec 7, 2016

View reviewed changes

nyeates added 3 commits December 15, 2016 00:07

removed typo

1c69700

Added idea on using cust. req. negotiation

5d4a893

Added @gruetter idea on using customer requirements elucidation/negotiation

Small reword

7627259

nyeates changed the title ~~Common Requirements PR~~ Pattern/Common Requirements Jan 17, 2017

nyeates added Ready for 2nd Review and removed Ready for Review labels Jan 19, 2017

nyeates requested a review from ErinMB January 19, 2017 06:47

nyeates changed the title ~~Pattern/Common Requirements~~ pattern/commonRequirements Jan 20, 2017

NewMexicoKid and others added 2 commits January 23, 2017 13:46

Fixed typo: isn't

9d7ef82

Merge branch 'master' into pattern/commonRequirements

3fb5b47

gruetter approved these changes Feb 8, 2017

View reviewed changes

nyeates changed the title ~~pattern/commonRequirements~~ pattern/common-requirements Mar 1, 2017

nyeates added 3-validated Patterns proven in multiple cases with advanced requirements (Please see our contribution handbook) and removed Pattern labels Mar 11, 2017

nyeates added 2 - Needs Revision and removed 5 - Finalize labels Mar 12, 2017

rshanmer added 4 - Finalize and removed 2 - Needs Revision labels Aug 31, 2017

Align with PLoP 2017 draft.

2faad14

rshanmer closed this Aug 31, 2017

rshanmer reopened this Aug 31, 2017

rshanmer merged commit 89d6e01 into master Aug 31, 2017

rshanmer deleted the pattern/commonRequirements branch August 31, 2017 20:14

spier mentioned this pull request Feb 8, 2022

Missing patterns related to Common Requirements pattern #386

Closed

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

Added the translation of dedicated community leader (#11)

4e8546f

* Added the translation of dedicated community leader * Fixed the lint error of dedicated-community-leader.md * Updated the translation with review comments

		Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects. Decompose the code into smaller pieces for which the many using projects can agree upon requirements.

		Additionally, take advantage of customers expecting the supplier to help elucidate requirements. Bring about the alignment of requirements during the customer negotiations and influence the customers requirements rather than changing the component.

pattern/common-requirements #11

pattern/common-requirements #11

Uh oh!

Conversation

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

Uh oh!

Uh oh!

nyeates commented Nov 30, 2016

Uh oh!

gruetter commented Dec 5, 2016

Uh oh!

nyeates commented Dec 5, 2016

Uh oh!

NewMexicoKid commented Dec 5, 2016

Uh oh!

gruetter commented Dec 6, 2016

Uh oh!

gruetter commented Dec 6, 2016

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!

Choose a reason for hiding this comment

Uh oh!

gruetter Dec 7, 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!

nyeates commented Dec 15, 2016

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rshanmer commented Aug 31, 2017

Uh oh!

Uh oh!

nyeates commented Nov 30, 2016 •

edited

Loading

gruetter Dec 7, 2016 •

edited

Loading