Fixes #72 adding detail to the contributor ethos. #102

MaineC · 2019-07-25T14:41:35Z

This follows the format of the introduction article, and the content suggestions from the outline.

rrrutledge

So neat! Left a few ideas.

contributor/03-contributor-ethos.md

rrrutledge · 2019-08-06T22:44:49Z

contributor/03-contributor-ethos.md

+
+With InnerSource projects there are several ways that code gets in:
+
+Sometimes you just open a pull request. At times you may need to get a feature request accepted before opening the pull request that fulfills it.


At times you may need to get a feature request accepted before opening the pull request that fulfills it.

This point is made with more detail in the paragraph In the same way that .... Suggest just deleting this sentence here since the point will be brought up later.

If we remove this sentence, then the case that sometimes a simple, well written PR could solve things would go missing. Maybe just rephrasing this would help

We want the point in the document, but I feel that it's made in the other paragraph anyway and so it just getting repeated here.

contributor/03-contributor-ethos.md

rrrutledge · 2019-08-06T22:47:59Z

contributor/03-contributor-ethos.md

+
+The host team will be the one taking over maintenance for your changes. It makes sense to offer to fulfill a 30-day warranty on your submission. This can alleviate the host teams' fear of the contributors not being available for support with fixing bugs after the time on contribution.
+
+Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.


I know you're just following the order in the outline, but as I read the article now I feel like this paragraph would go better. before the paragraphs on "selling".

In the sense of "this gives the contributing person good arguments for the sale / allows them to make a good offer"?

Not necessarily - it just seems related to the paragraph that is already before the "selling" section.

rrrutledge · 2019-08-06T22:50:03Z

contributor/03-contributor-ethos.md

+
+Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.
+
+#### Anticipate and follow house rules


Is there a way to make this section a little more conversational with some flow to it? Right now all of the information is there but it looks like just the straight text of the bullet points without any other structure to make it enjoyable to read.

I agree, this reads like a checklist / manual. I don't instantly have any good suggestions here though.

I've tried to re-phrase the entire paragraph. One thing I was struggling with was finding a good real world story of walking in with an open sign out up to making an appointment. So I've changed the narrative a bit.

Oh you've done some wonderful writing, but my comment was meant for the Anticipate and follow house rules section (rather than the Getting in section).

Ups :) I'll look at the other section as well then.

contributor/03-contributor-ethos.md

lenucksi

Thanks for making this. GitHub doesn't let me insta-accept/close the typo corrections though.

lenucksi · 2019-08-07T11:07:51Z

contributor/03-contributor-ethos.md

+
+The host team will be the one taking over maintenance for your changes. It makes sense to offer to fulfill a 30-day warranty on your submission. This can alleviate the host teams' fear of the contributors not being available for support with fixing bugs after the time on contribution.
+
+Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.


In the sense of "this gives the contributing person good arguments for the sale / allows them to make a good offer"?

lenucksi · 2019-08-07T11:09:35Z

contributor/03-contributor-ethos.md

+
+Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.
+
+#### Anticipate and follow house rules


I agree, this reads like a checklist / manual. I don't instantly have any good suggestions here though.

contributor/03-contributor-ethos.md

lenucksi · 2019-08-07T11:24:17Z

contributor/03-contributor-ethos.md

+
+With InnerSource projects there are several ways that code gets in:
+
+Sometimes you just open a pull request. At times you may need to get a feature request accepted before opening the pull request that fulfills it.


If we remove this sentence, then the case that sometimes a simple, well written PR could solve things would go missing. Maybe just rephrasing this would help

lenucksi · 2019-08-07T11:24:22Z

contributor/03-contributor-ethos.md

+
+In some organisations you may need to talk to the host team in person in addition to interacting with the project digitally. 
+
+In the same way that real-life hosts don't always appreciate a stranger knocking on their door, some InnerSource hosts appreciate some heads-up before seeing a pull request gets opened to their repo. Typically there will be an issue tracker where new features are discussed before being submitted as a pull request. A useful alternative are archived, searchable, linkable but unstructured discussion platforms: Thank of mailing lists, chat plattforms or online fora.


Just split this large paragraph up into individual lines to allow for easier reviewing.

Suggested change

In the same way that real-life hosts don't always appreciate a stranger knocking on their door, some InnerSource hosts appreciate some heads-up before seeing a pull request gets opened to their repo. Typically there will be an issue tracker where new features are discussed before being submitted as a pull request. A useful alternative are archived, searchable, linkable but unstructured discussion platforms: Thank of mailing lists, chat plattforms or online fora.

In the same way that real-life hosts don't always appreciate a stranger knocking on their door, some InnerSource hosts appreciate some heads-up before seeing a pull request gets opened to their repo.

Typically there will be an issue tracker where new features are discussed before being submitted as a pull request.

A useful alternative are archived, searchable, linkable but unstructured discussion platforms: Thank of mailing lists, chat plattforms or online fora.

Along the same lines according to the updated outline #99 we should definitely strongly highlight the value of keeping as much in the archived, indexed public as possible. Might even want to encourage the TCs (article) to continuously encourage such behavior as this tends to be forgotten over time in many organizations.

arnom-ms · 2019-08-07T18:07:51Z

contributor/03-contributor-ethos.md

+
+#### Anticipate and follow house rules
+
+The README.md or CONTRIBUTING.md often not only contains information about how to approach the host team, but also guidelines throughout the contribution process. Be sure to understand and follow them.


I would like to make a greater distinction between README.md and CONTRIBUTING.md. I suggest we suggest (:-)) to use the README.md to explain what the project is about and how to USE, Build and get started with it. In contrast, the CONTRIBUTING.md should be used to describe HOW TO CONTRIBUTE to the project (process wise, code styles, test expectations etc). Maybe I should open an issue for review on docs in general?

I like it. I the long run we really need a pattern/template on this, too. @lenucksi was talking about doing that once.

I think it makes sense to be a bit more specific in this paragraph, however I wouldn't strictly forbid contributing related docs in the README. More like: If you don't find contributing related documentation in the README they have been split out into CONTRIBUTING.md

The reasoning behind that: For small enough projects both sides of the documentation can be short enough to be kept in one document (in particular if the project uses standard development tooling and best practices**). Even if they are split, the contributor will still have to read the README anyway to first understand how the project works and can be used before even thinking about contributing.

Makes sense?

** Which should be a pattern to follow for projects to lower barriers for contributions.

I agree with both opinions.
To me it appears that the shared goal is to prevent too long documentation and enable easier absorption of the knowledge contained in the documents.

With larger projects separation is totally great, with the smaller ones, combining them is fine too. What we could provide is a guidance when to separate such documents and how to arrive at a (set of) document(s) that serve their purpose well.
I was working at such documents a while ago, let's see what became of them.

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Co-Authored-By: Johannes Tigges <lenucksi@users.noreply.github.com>

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Co-Authored-By: Johannes Tigges <lenucksi@users.noreply.github.com>

rrrutledge

A few comments I forgot to submit the other day.

rrrutledge · 2019-08-07T19:03:56Z

contributor/03-contributor-ethos.md

+
+With InnerSource projects there are several ways that code gets in:
+
+Sometimes you just open a pull request. At times you may need to get a feature request accepted before opening the pull request that fulfills it.


We want the point in the document, but I feel that it's made in the other paragraph anyway and so it just getting repeated here.

rrrutledge · 2019-08-07T19:05:14Z

contributor/03-contributor-ethos.md

+
+The host team will be the one taking over maintenance for your changes. It makes sense to offer to fulfill a 30-day warranty on your submission. This can alleviate the host teams' fear of the contributors not being available for support with fixing bugs after the time on contribution.
+
+Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.


Not necessarily - it just seems related to the paragraph that is already before the "selling" section.

rrrutledge · 2019-08-07T19:06:26Z

contributor/03-contributor-ethos.md

+
+#### Anticipate and follow house rules
+
+The README.md or CONTRIBUTING.md often not only contains information about how to approach the host team, but also guidelines throughout the contribution process. Be sure to understand and follow them.


I like it. I the long run we really need a pattern/template on this, too. @lenucksi was talking about doing that once.

We've been trying to use this spelling in the learning path.

rrrutledge

Looks awesome to me. Thank you, Isabel!!

Fixes InnerSourceCommons#72 adding detail to the contributor ethos.

21d6898

This follows the format of the introduction article, and the content suggestions from the outline.

lenucksi added the Contributor label Aug 6, 2019

rrrutledge requested changes Aug 6, 2019

View reviewed changes

lenucksi self-requested a review August 7, 2019 11:02

lenucksi reviewed Aug 7, 2019

View reviewed changes

arnom-ms reviewed Aug 7, 2019

View reviewed changes

MaineC and others added 7 commits August 8, 2019 09:18

Update contributor/03-contributor-ethos.md

ce8a9e8

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Update contributor/03-contributor-ethos.md

f899a80

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Update contributor/03-contributor-ethos.md

f6bf3b0

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Update contributor/03-contributor-ethos.md

e767d3b

Co-Authored-By: Johannes Tigges <lenucksi@users.noreply.github.com>

Update contributor/03-contributor-ethos.md

d716472

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Update contributor/03-contributor-ethos.md

1bbe186

Co-Authored-By: rrrutledge <rrrutledge@users.noreply.github.com>

Update contributor/03-contributor-ethos.md

ecf97ad

Co-Authored-By: Johannes Tigges <lenucksi@users.noreply.github.com>

rrrutledge mentioned this pull request Aug 8, 2019

Article: The Contributor Ethos #72

Closed

rrrutledge reviewed Aug 8, 2019

View reviewed changes

Re-phrase paragraph about knocking on the door.

b414d8b

lenucksi added the Article label Aug 15, 2019

MaineC and others added 2 commits August 20, 2019 11:48

Modify house rule section.

68d1c0e

Inner Source -> InnerSource

cebcea3

We've been trying to use this spelling in the learning path.

rrrutledge approved these changes Aug 20, 2019

View reviewed changes

MaineC merged commit 05bf414 into InnerSourceCommons:master Aug 21, 2019


		With InnerSource projects there are several ways that code gets in:

		Sometimes you just open a pull request. At times you may need to get a feature request accepted before opening the pull request that fulfills it.


		The host team will be the one taking over maintenance for your changes. It makes sense to offer to fulfill a 30-day warranty on your submission. This can alleviate the host teams' fear of the contributors not being available for support with fixing bugs after the time on contribution.

		Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.


		Many InnerSource projects outline how they like to be approached by potential Contributors in their README.md or CONTRIBUTING.md files. Following those recommendations greatly increases your chances of getting your contribution accepted.

		#### Anticipate and follow house rules


		In some organisations you may need to talk to the host team in person in addition to interacting with the project digitally.

		In the same way that real-life hosts don't always appreciate a stranger knocking on their door, some InnerSource hosts appreciate some heads-up before seeing a pull request gets opened to their repo. Typically there will be an issue tracker where new features are discussed before being submitted as a pull request. A useful alternative are archived, searchable, linkable but unstructured discussion platforms: Thank of mailing lists, chat plattforms or online fora.


		#### Anticipate and follow house rules

		The README.md or CONTRIBUTING.md often not only contains information about how to approach the host team, but also guidelines throughout the contribution process. Be sure to understand and follow them.

Fixes #72 adding detail to the contributor ethos. #102

Fixes #72 adding detail to the contributor ethos. #102

Uh oh!

Conversation

MaineC commented Jul 25, 2019

rrrutledge left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

lenucksi left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MaineC Aug 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rrrutledge left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rrrutledge left a comment

Choose a reason for hiding this comment

Labels

4 participants

MaineC Aug 8, 2019 •

edited

Loading