Skip to content

Fix new site links #390

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.

Sign up for GitHub

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

Merged
tsadler1988 merged 2 commits into from
Apr 1, 2021
Merged

Fix new site links #390

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
72816df
Change all links in articles to new live site
tsadler1988 Mar 31, 2021
154697f
Merge branch 'master' into fix-new-site-links
tsadler1988 Mar 31, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
158 changes: 52 additions & 106 deletions config/urls.yaml
View file
Open in desktop

Large diffs are not rendered by default.

12 changes: 6 additions & 6 deletions contributor/01-introduction-article.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,15 @@ If you're not getting what you need, you can make the change you need directly i
The Contributor role describes a person that makes contributions to the repos of an InnerSource community project.
This person may or may not be part or see themselves as part of the community.
However, for quite a few people there is a sort of journey that contributors can make from just knowing about the community to using the community's product to interacting with members of the community and finally starting to contribute.
Finally, some of them may become https://innersourcecommons.org/resources/learningpath/trusted-committer/index[Trusted Committers].
Finally, some of them may become https://innersourcecommons.org/learn/learning-path/trusted-committer/01[Trusted Committers].

=== Relationship to other roles

As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] or https://innersourcecommons.org/resources/learningpath/product-owner/index[_Product Owner_] and possibly with other contributors.
As a Contributor in an InnerSource community you will interact with people playing other roles of InnerSource, such as https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] or https://innersourcecommons.org/learn/learning-path/product-owner/01[_Product Owner_] and possibly with other contributors.
At times, these roles can be played by the same person, such as Trusted Committer and Product Owner in small grassroots style projects.

This section gives you a very short overview of the other two roles, but we'd like to encourage you to read the https://innersourcecommons.org/resources/learningpath/trusted-committer/index[introductory article of the Trusted Committer role], and we recommended you read the https://innersourcecommons.org/resources/learningpath/trusted-committer/05/[Lowering the barriers to entry] article, too, before you delve deeper into the details of the Contributor role in this section.
You can also watch the videos (https://innersourcecommons.org/resources/learningpath/trusted-committer/index[introduction], https://innersourcecommons.org/resources/learningpath/trusted-committer/05/[lowering the barriers to entry]) instead of reading the articles.
This section gives you a very short overview of the other two roles, but we'd like to encourage you to read the https://innersourcecommons.org/learn/learning-path/trusted-committer/01[introductory article of the Trusted Committer role], and we recommended you read the https://innersourcecommons.org/learn/learning-path/trusted-committer/05/[Lowering the barriers to entry] article, too, before you delve deeper into the details of the Contributor role in this section.
You can also watch the videos (https://innersourcecommons.org/learn/learning-path/trusted-committer/01[introduction], https://innersourcecommons.org/learn/learning-path/trusted-committer/05/[lowering the barriers to entry]) instead of reading the articles.

==== Trusted Committer

Expand All @@ -33,7 +33,7 @@ Caring for the community involves keeping it healthy, upleveling it and its part

==== Product Owner

The role of the https://innersourcecommons.org/resources/learningpath/product-owner/index[_Product Owner_] has some similarity with the product owner role of your average project.
The role of the https://innersourcecommons.org/learn/learning-path/product-owner/01[_Product Owner_] has some similarity with the product owner role of your average project.
However, there are differences - depending on the size of the project, this role is often filled by the same person that acts as trusted committer.
In larger projects, or in teams that only partially use InnerSource as an approach to fill their needs by accepting contributions, this role is likely filled by a person separate from a trusted committer.

Expand All @@ -42,7 +42,7 @@ You might work with the product owner role to make sure that general aspects of

Last but not least, someone acting as product owner might have been involved in bringing the project, its benefits and community to your attention.

If you want to learn in more detail what these other roles are about, and we encourage you to do so, we've prepared separate sections about the https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] and the https://innersourcecommons.org/resources/learningpath/product-owner/index[_Product Owner_].
If you want to learn in more detail what these other roles are about, and we encourage you to do so, we've prepared separate sections about the https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] and the https://innersourcecommons.org/learn/learning-path/product-owner/01[_Product Owner_].

=== Section overview

Expand Down
14 changes: 7 additions & 7 deletions contributor/04-mechanics-of-contributing-article.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ This effect can be observed with Open Source as well, you can read more about it
In your classic teams everyone had an idea of the expected lead times.
Within an InnerSource context this might not be the case, either due to large time-zone differences (e.g. Seattle, USA with PDT vs Berlin, Germany with CEST) or you not being available full-time as with your original team, even if they are in the same physical location as you are.
Thus, to prevent frustration on both sides, impatience and other non-trust-building effects, you'll need to explicitly do expectations management with regards to your expected reaction times.
One approach is to just quickly react with a "I'll look into it, I won't get to it in the next few days though" to a https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer's_] feedback if you know that you'll only be able to come back to them in a few days.
One approach is to just quickly react with a "I'll look into it, I won't get to it in the next few days though" to a https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer's_] feedback if you know that you'll only be able to come back to them in a few days.
Ideally, you can provide them with a rough estimate when you will likely have time to take a look at their input.
Doing so builds trust by reliability even over non-physical contact, longer distance or otherwise asynchronous media.
Established trust will allow you to overcome uncertainty bumps in the collaborative road ahead of you.
Expand All @@ -60,7 +60,7 @@ This challenge is a frequent one, and many team relationships suffered from not

Make yourself and the host team happy (and possibly save some work) by getting agreement from the host team on the user/technical design of the contribution _before_ working on the changes and submitting a pull request.
You'll have to understand how the host team would like you to reach out for this.
It's best to ask a https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] about how to best discuss your proposal.
It's best to ask a https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] about how to best discuss your proposal.

It is time-and-again-proven wisdom from the Open Source arena that, if you get to select how to discuss your proposal, you should try to select a written way.
Ideally, choose the way where artifacts are public, searchable and perma-linkable to enable referencing your proposal in later discussions on this future contribution or other contributions to come - by you or others.
Expand Down Expand Up @@ -103,19 +103,19 @@ Project teams are often happy to receive additions, updates or corrections for t

We all have our preferences and opinions on code style, indentation, etc.
The host team's project has them as well.
Try to adapt and match those preferences even if it's not what you would normally do, and even if it is not specified in the projects' https://innersourcecommons.org/resources/learningpath/trusted-committer/05/[_`CONTRIBUTING.md`_].
Try to adapt and match those preferences even if it's not what you would normally do, and even if it is not specified in the projects' https://innersourcecommons.org/learn/learning-path/trusted-committer/05/[_`CONTRIBUTING.md`_].
If you are unsure, you can always ask politely. Nevertheless, a guest contribution for a feature or a bug fix is not the time to introduce a new way of structuring or formatting project code.

=== Submitting the pull request

You've completed all the essential work, figured out all the quirks of the problem and the project you are contributing to, the time you've planned for the new feature to be used comes nearer, and you want to make sure your contribution gets merged in as fast and smooth as possible.

Here's what you can do to make reviewing and merging as easy as possible for the the https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] and the host team.
Here's what you can do to make reviewing and merging as easy as possible for the the https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] and the host team.
This might actually be pretty similar to what you may already be doing on your own project to get your changes accepted. If that's the case - great, this is going to come natural to you!

==== Testing and automation

The basic point here is to enable the https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] to validate the contribution without your presence and to ensure easy maintainability.
The basic point here is to enable the https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] to validate the contribution without your presence and to ensure easy maintainability.
Imagine you've built a feature or handling of an unsolvable quirk, or an important performance tweak, and your code is not entirely obvious (or might even look hacky / wrong at the first glance).
If you have covered this with a test - and ideally have shed some words on the rationale behind it in a comment - a future editor will get reminded about the purpose of the code, and the test(s) will ensure that the value your code realizes will be kept, even in the new implementations.
To achieve this, do the following:
Expand All @@ -141,11 +141,11 @@ To make the actual code review as easy as possible for the trusted committer or
* Provide a clear description of what this pull request changes, why it does so, and which issue and design documents (if there were any) it refers to.
* If there is anything uncommon or unexpected in the pull request, highlight it and provide the explanation. This will make it easier to reason about and solve potential blocking questions that a reviewer might have during the review.
** The same goes for the scenario where you were unsure of the implementation or your approach - highlight it and ask for an insight.
** Be civil and expect civility from the https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer's_] review.
** Be civil and expect civility from the https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer's_] review.
* Making pull requests too broad and large makes them more difficult to review, so it will take much longer before they're accepted.
** If you have a larger feature that you are contributing, it often helps to split it in multiple pull requests that are submitted, reviewed and accepted sequentially.
You can still bind them together with an issue that you are referring to.
*** Some tools also have Draft / WIP pull request functionality that you can use to explicitly mark unfinished and non-polished work and still get early feedback from your host team's https://innersourcecommons.org/resources/learningpath/trusted-committer/02/[_Trusted Committers_].
*** Some tools also have Draft / WIP pull request functionality that you can use to explicitly mark unfinished and non-polished work and still get early feedback from your host team's https://innersourcecommons.org/learn/learning-path/trusted-committer/02/[_Trusted Committers_].
*** This allows you to ensure that you are going down a path that your host team is happy to merge once it's done, adhering to the "release early, release often" idea in a way.
*** The host team's responsibility is to create an atmosphere where sharing and discussing not-totally-polished work is possible and welcome. If you can't fail safe, you can't innovate, and collaboration becomes very hard.
*** Try to balance between asking for a review early and providing meaningful changes to review.
Expand Down
12 changes: 6 additions & 6 deletions contributor/de/01-introduction-article-de.asciidoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,17 +12,17 @@ Wenn Du nicht bekommst, was Du benötigst, kannst Du die notwendige Änderung di
Die Rolle des Contributors beschreibt eine Person, die zu den Repositories einer InnerSource Community beiträgt.
Diese Person kann, muss aber nicht, Teil der Communitiy sein.
Für nicht wenige Leute gibt es einen Weg, wie man als Contributor vom Zustand "ich kenne die Gemeinschaft" über "ich nutze das Produkt der Community und interagiere mit ihr" bis hin zu "ich trage zum Produkt der Community bei" gelangt.
Am Ende werden einige sogar https://innersourcecommons.org/resources/learningpath/trusted-committer/index[Trusted Committers].
Am Ende werden einige sogar https://innersourcecommons.org/learn/learning-path/trusted-committer/01[Trusted Committers].

=== Zusammenspiel mit anderen Rollen

Als Contributor in einer InnerSource Community interagiert man mit Personen in anderen Rollen der InnerSource Community, wie dem
https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] oder dem https://innersourcecommons.org/resources/learningpath/product-owner/index[_Product Owner_] und wahrscheinlich mit anderen Contributoren.
https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] oder dem https://innersourcecommons.org/learn/learning-path/product-owner/01[_Product Owner_] und wahrscheinlich mit anderen Contributoren.
Manchmal übernimmt eine Person mehrere Rollen, z. B. die des Trusted Committer und des Product Owner speziell in kleineren Projekten.

Im Folgenden findest Du einen sehr kurzen Überblick über die anderen Rollen, aber wir möchten Dich ermutigen, die weiterführenden Artikel
https://innersourcecommons.org/resources/learningpath/trusted-committer/index[introductory article of the Trusted Committer role] und https://innersourcecommons.org/resources/learningpath/trusted-committer/05/[Lowering the barriers to entry] zu lesen, bevor Du Dich tiefer in die Details der Contributor Rolle in diesem Abschnitt einarbeitest.
Alternativ kannst Du Dir auch unsere Videos zu den Themen anschauen: https://innersourcecommons.org/resources/learningpath/trusted-committer/index[introduction], https://innersourcecommons.org/resources/learningpath/trusted-committer/05/[lowering the barriers to entry].
https://innersourcecommons.org/learn/learning-path/trusted-committer/01[introductory article of the Trusted Committer role] und https://innersourcecommons.org/learn/learning-path/trusted-committer/05/[Lowering the barriers to entry] zu lesen, bevor Du Dich tiefer in die Details der Contributor Rolle in diesem Abschnitt einarbeitest.
Alternativ kannst Du Dir auch unsere Videos zu den Themen anschauen: https://innersourcecommons.org/learn/learning-path/trusted-committer/01[introduction], https://innersourcecommons.org/learn/learning-path/trusted-committer/05/[lowering the barriers to entry].

==== Trusted Committer

Expand All @@ -35,15 +35,15 @@ Sich um die Community zu kümmern beinhaltet es, die Community attraktiv zu halt

==== Product Owner

Die Rolle des https://innersourcecommons.org/resources/learningpath/product-owner/index[_Product Owner_] ähnelt der Rolle des Product Owners im klassischen Sinn.
Die Rolle des https://innersourcecommons.org/learn/learning-path/product-owner/01[_Product Owner_] ähnelt der Rolle des Product Owners im klassischen Sinn.
Trotzdem gibt es Unterschiede - abhängig von der Größe des Projekts hat diese Rolle oft die gleiche Person inne, die auch als Trusted Committer agiert.
In größeren Projekten oder in Teams, die InnerSource nur teilweise als Ansatz verwenden um ihre Anforderungen durch das Akzeptieren von Beiträgen zu erfüllen, werden die Rollen des Product Owners und des Trusted Committers in der Regel von unterschiedlichen Personen wahrgenommen.

Deine Zusammenarbeit mit dem Product Owner wird sich wahrscheinlich darauf konzentrieren, dass Dein Beitrag in die generelle Produktstrategie und Roadmap passt. Du kannst mit dem Produkt Owner zusammenarbeiten, um sicherzustellen, dass allgemeine Aspekte der Dokumentation oder die Konsistenz von UI / UX beim mergen Deines Beitrags erhalten bleiben.

Möglicherweise ist der Product Owner auch daran beteiligt, Dich auf das Projekt, auf seine Vorteile, und auf die Cummunity selbst aufmerksam zu machen.

Wir emutigen Dich mehr über die anderen Rollen zu lernen, und haben deshalb weitere Artikel über den https://innersourcecommons.org/resources/learningpath/trusted-committer/index[_Trusted Committer_] und den https://innersourcecommons.org/resources/learningpath/product-owner/index[_Product Owner_] für Dich vorbereitet.
Wir emutigen Dich mehr über die anderen Rollen zu lernen, und haben deshalb weitere Artikel über den https://innersourcecommons.org/learn/learning-path/trusted-committer/01[_Trusted Committer_] und den https://innersourcecommons.org/learn/learning-path/product-owner/01[_Product Owner_] für Dich vorbereitet.

=== Kapitel Übersicht

Expand Down
Loading