Create 04-mechanics-of-contributing-article-de.asciidoc#463
Create 04-mechanics-of-contributing-article-de.asciidoc#463rrrutledge merged 25 commits intomasterfrom
Conversation
fioddor
added
Contributor
Translation
lenucksi
left a comment
lenucksi
left a comment
There was a problem hiding this comment.
Added a number of commit suggestions and annotations for change.
We should, in theory, also review in the end - probably the entire LP - for consistency in terms. That's quite the hard work. There's some tooling for it though.
If we have a small go at the article here wrt to term consistency it's also fine.
Also, I suck at commas. So we'll need a German (native speaker) with comma skills such as @MaineC or @arnom-ms to give it a second look.
| * <<vorbereitungen-für-die-arbeit,Einholen des Beitragsangebots und Vorbereitung auf die Arbeit>> | ||
| * <<erstellen-des-pull-requests,Den Beitrag tatsächlich erstellen>> | ||
| * <<einreichen-des-pull-requests,Polieren und Verpacken des Geschenks und Überreichen an das Gastgeberteam>>. |
There was a problem hiding this comment.
This looks like there used to be markdown links that are broken. Probably needs to be fixed.
| Beginnen Sie früh genug, damit Ihre Arbeit zu dem Zeitpunkt, an dem Sie sie brauchen, zur Verfügung steht. | ||
| Es ist besser, anfangs mehr Zeit einzuplanen - Sie werden ein Gefühl für die Bearbeitungszeiten bekommen, wenn Sie mit dem Gastteam zusammenarbeiten. | ||
| Häufig werden Sie feststellen, dass sich die Durchlaufzeiten pro Host-Team verringern, nachdem Sie einige erfolgreiche Beiträge für dieses Host-Team geleistet haben. | ||
| Dieser Effekt ist auch bei Open Source zu beobachten, mehr dazu können Sie <<vertrauensbildung-durch-zusammenarbeit,hier>> lesen. |
|
I'll be fixing the links somewhere in the week and then merge it. |
Thank you, @lenucksi ❗ |
The opening question mark was missing.
Needed to render under Workbook tile.
* Clean up Scribe documentation * Update example to match actual agenda wording
|
Hey @lenucksi @nysenthil are either of you able to pick this up? No problem if not, we can reach out to others. |
|
Comments from @nysenthil attached. innersourcecommons-english-to-german-translation-verification.docx |
tjohnson31415
left a comment
tjohnson31415
left a comment
There was a problem hiding this comment.
These suggested changes come from the .docx file posted in this comment. These are not my translations.
There are a couple cases where I excluded the suggested change because I felt that the term should remain untranslated.
- "Problem" was suggested as a translation for "Issue", but "Issue" in reference to GitHub issue should probably remain untranslated
- on line 149 "verbindet" was suggested for "merged"
- in some instances "Gastgeberteam" was suggested for "host team". It isn't clear to me if "host team" should remain untranslated or not, but I left "host team".
|
Thank you for this update, @tjohnson31415 ❗ 🎉 Perhaps one of our German-speaking members - @lenucksi or @gruetter ? - could accept these commit suggestions? |
Co-authored-by: Travis Johnson <tjohnson31415@gmail.com>
Co-authored-by: Johannes Tigges <lenucksi@users.noreply.github.com>
gruetter
left a comment
gruetter
left a comment
There was a problem hiding this comment.
Hey @tjohnson31415 : thank you so much for this contribution! I have a couple of suggestions and identified a few places that should be polished for readability. Also, there's some non-German content at the end.
| Bei jedem erstmaligen Beitrag kommen Sie zu einem neuen (Gast-)Team. | ||
| Daher müssen Sie deren Codebasis, die verwendeten Technologien und auch deren bevorzugte Entwicklungsumgebung (z. B. Test-Framework, Build-System) kennen lernen. | ||
| Selbst in Fällen, in denen diese Art von Tooling standardisiert ist, wird jedes Team einige individuelle Eigenheiten entwickelt haben. | ||
| Neben der technischen Seite können Sie auch mit Unterschieden in der Kommunikation konfrontiert werden (z. B. Code-Reviews). |
There was a problem hiding this comment.
Meine Erfahrung ist das auch der verwendete Prozess eine Kontribution zu machen - die Mechanik sozusagen - sehr wichtig ist. Insbesondere das Branching-Modell unterscheidet sich oft von Team zu Team und ist nicht selten Gegenstand heisser Debatten. Würde ich vorschlagen zu erwähnen. Ein Hinweis auf die CONTRIBUTING.md wäre vlt. auch hilfreich.
| Um also Frustration auf beiden Seiten, Ungeduld und andere nicht vertrauensbildende Effekte zu vermeiden, müssen Sie explizit ein Erwartungsmanagement in Bezug auf Ihre erwarteten Reaktionszeiten betreiben. | ||
| Eine Möglichkeit ist es, auf das Feedback eines https://innersourcecommons.org/de/learn/learning-path/trusted-committer[_Trusted Committers_] schnell mit einem "Ich kümmere mich darum, werde aber in den nächsten Tagen nicht dazu kommen" zu reagieren, wenn Sie wissen, dass Sie erst in ein paar Tagen darauf zurückkommen können. | ||
| Idealerweise können Sie ihm eine grobe Schätzung geben, wann Sie wahrscheinlich Zeit haben werden, um sich seinen Beitrag anzusehen. | ||
| Auf diese Weise schaffen Sie Vertrauen durch Verlässlichkeit, selbst bei nicht physischem Kontakt, größerer Entfernung oder anderen asynchronen Medien. |
There was a problem hiding this comment.
Sollten diese beiden Zeilen vielleicht in den nächsten Abschnitt?
| Natürlich nicht: Während die schriftliche Kommunikation im Hinblick auf die Archivierung und Durchsuchbarkeit von Vorteil ist, ist die persönliche Kommunikation im Hinblick auf die Kommunikationsbandbreite von Vorteil. | ||
| Versuchen Sie, sich Zeit zu nehmen, um sich mit den Menschen hinter den Namen zu treffen. Wenn möglich, treffen Sie sich mit ihnen bei Ihrem Lieblingsgetränk oder einem Essen. | ||
| Wenn Sie die Menschen sprechen hören können und ihre Eigenheiten kennen, wird die Zusammenarbeit aus der Ferne einfacher. | ||
|
|
There was a problem hiding this comment.
Ich würde vorschlagen noch zu erwähnen, dass das für schriftlichen von Diskussion hilfreich ist. Apache Motto: if it was not written down, it did not happen.
| Wäre es nicht furchtbar, wenn Ihre ganze Arbeit umsonst wäre? | ||
| Das kann passieren, wenn das Team des Gastgebers bereits etwas sehr Ähnliches entwickelt, die Software veraltet ist oder das, was Sie vorschlagen, nicht in das Projekt passt. | ||
| Dieses Problem tritt häufig auf, und viele Teambeziehungen haben darunter gelitten, dass man sich nicht im Voraus einig war, dass ein Beitrag gut passt. | ||
|
|
There was a problem hiding this comment.
I habe trouble grokking this sentence.
| * Wenn Sie Pull Requests zu umfangreich gestalten, wird es schwieriger, sie zu prüfen, so dass es viel länger dauern wird, bis sie akzeptiert werden. | ||
| ** Wenn Sie ein größeres Feature beisteuern, hilft es oft, es in mehrere Pull Requests aufzuteilen, die nacheinander eingereicht, geprüft und akzeptiert werden. | ||
| Sie können sie immer noch mit einem Issue zusammenbinden, auf das Sie sich beziehen. | ||
| *** Einige Tools haben auch eine Draft / WIP Pull Request Funktion, die Sie benutzen können, um unfertige und nicht ausgefeilte Arbeit zu markieren und trotzdem frühes Feedback von den https://innersourcecommons.org/de/learn/learning-path/trusted-committer/02/[_Trusted Committers_] Ihres Host-Teams zu bekommen. |
There was a problem hiding this comment.
Das ist auch ohne tools möglich und sinnvoll. Man kann ja einen PR starten aber noch niemand zum review einladen sondern stattdessen im frühes Feedback oder Hilfe bitten.
Co-authored-by: Travis Johnson <tjohnson31415@gmail.com>
Co-authored-by: Travis Johnson <tjohnson31415@gmail.com>
Co-authored-by: Travis Johnson <tjohnson31415@gmail.com>
Co-authored-by: Georg Grütter <gruetter@gmail.com>
Co-authored-by: Georg Grütter <gruetter@gmail.com>
Co-authored-by: Travis Johnson <tjohnson31415@gmail.com>
Co-authored-by: Johannes Tigges <lenucksi@users.noreply.github.com>
Co-authored-by: Johannes Tigges <lenucksi@users.noreply.github.com>
Co-authored-by: Georg Grütter <gruetter@gmail.com>
|
Thanks for this work, @fioddor ❗️ What is next or what is left to do on this article to get it “done”? |
Committing changes to the documents before final review Co-authored-by: Georg Grütter <gruetter@gmail.com> Co-authored-by: Johannes Tigges <lenucksi@users.noreply.github.com>
Committing changes to the documents before final review Co-authored-by: Georg Grütter <gruetter@gmail.com>
|
Thanks for these updates, @tjohnson31415 ❗ Has this work had an “over-the-shoulder” review from a native German speaker? |
Updates and applies change where there were two suggested changes. The overlapping one was "bevorzugen - das" to "bevorzugen. Das"
|
@rrrutledge: I am cleaning up the PR to incorporate all of the suggestions before final review. The commits I created are just from "Suggested Changes" that had already been posted by native speakers. |
This is the final review of this German translated text. IBM Research senior manager Horst Samulowitz did the review, made a few corrections and approved.
tjohnson31415
left a comment
tjohnson31415
left a comment
There was a problem hiding this comment.
I checked the links that were marked as broken to confirm that they are working now.
|
|
||
| Machen Sie sich selbst und das Team des Gastgebers glücklich (und sparen Sie möglicherweise etwas Arbeit), indem Sie die Zustimmung des Teams des Gastgebers zum Benutzer/technischen Design des Beitrags einholen, _bevor_ Sie an den Änderungen arbeiten und einen Pull Request einreichen. | ||
| Sie müssen verstehen, wie das Team des Gastgebers möchte, dass Sie dies erreichen. | ||
| Am besten fragen Sie einen https://innersourcecommons.org/de/learn/learning-path/trusted-committer[_Trusted Committer_], wie Sie Ihren Vorschlag am besten besprechen können. |
rrrutledge
dismissed stale reviews from gruetter and lenucksi
Comments are handled
7 participants
Automatic translation. Links fixed. Ready for review by native speaker.
Helps #254