TODO Guide Employee Open Source Engagement Guide: Principle 1 - Starts Early

[jlprat]

Issue to track progress of the Principle: Starts Early. This came out of the discussions about organizations showing up with mature, fully baked contributions over which the community had no input.

For reference

• Notes from initial meeting
• Initial notes from Sustain WG discussion

[awright]

I'm going to start riffing on this, as insomnia added some thoughts to the mix. I do suggest someone clearly articulates the problem this seeks to address. (And I even recommend @DuaneOBrien for that) Would be hard pressed now to succinctly (or eloquently) articulate the problem, so riff here sort of assumes it.

tl;dr: Starting early means contributing to an open source project before things are "done". Doing this...

• builds trust. With trust orgs learn the levers to contribute.
• shows humility. Starting early prioritizes learning and offers respect to the expertise and history of the community.
• allows people/orgs to map the informal network and norms of the project.
• shifts organizational contribution from US/ME to WE: Not "I am going to fix things" but "We are going to make something together"

Suggested "tactics for start early contributors

• before you have code, join the discussion, track changes, and listen.
• ask questions
• pick up the easy work. start contributing to community needs already identified.
• always be transparent about where you come from (eg the org that pays your bills)
• when you first join a community, don't be afraid to acknowledge (flatter?) those who contributed before you.
• starting early means talking/contributing before things are perfect. don't be afraid to show yourself. use levity and be a human -- no one is a widget in a community -- but be careful with your language and humor. these people don't know you yet, and your probably not that funny anyway. ;)
• this is a geographically diverse and most likely international space. when you start early, listen and be mindful of differences, e.g language differences, racial differences, pay differences.
• show your work, show your process, show your thinking -- before it's done.
• be excited, you're here early, for a reason.

Some observations It's bad when a person/org jumps into a project and just dumps code. There's no space for learning, for collaborative creation. It can be arrogant and disrespectful to what's been done before. The best organizations come with ideas but more importantly, come with humility. They come to learn and contribute. The definition of contribution is probably important here, because contribute is about service. Few orgs come to a community in service to the project first.

[cornelius]

Semi-serious remark: We don't want people to join projects from the peak of Dunning-Kruger's "Mount Stupid".

[DavidPHirsch]

some suggestions:

• it is an easy place to start for non-technical people, setting up calendars, governance and other community oriented docs a very valuable and doesn't require to specific knowledge.
• if you are new to open source, this is a good point in a projects lifecycle to learn how pull requests, forking/branching, review and more work.

[jlprat]

Taking an attempt to put things in prose.

"One might be tempted to start with their contributions (even for the non-code ones) right away, but this is rarely the best approach to establish a good long-lasting relationship with the given Open Source Community. First of all, one must get to know the community: how it works, what are its needs, and how it is governed. Once this is done, one must start engaging with the community (in their desired ways) expressing the willingness to contribute to the project. Always take a humble and transparent approach, with eagerness to learn and collaborate. Once identified what one can contribute, it's always best to share their intentions, ideas, and approach for it. Sharing early and often helps in building a relationship as well as being mindful with everyone's time."

Let me know if this is something that would make sense as a description for this principle. Also, if this is the style and way we want to describe them.

[awright]

This is wonderful Josep!

Two things that jump out to me as missing:

• I think we should use the word “trust” somewhere. Starting early, learning from the community, etc speaks to me about building trust with others.
• Should we say something explicitly about coming from a company? Transparency about this matters. What do you think?

On Mon, Mar 14, 2022 at 7:46 AM, Josep Prat @.***> wrote:

Taking an attempt to put things in prose.

"One might be tempted to start with their contributions (even for the non-code ones) right away, but this is rarely the best approach to establish a good long-lasting relationship with the given Open Source Community. First of all, one must get to know the community: how it works, what are its needs, and how it is governed. Once this is done, one must start engaging with the community (in their desired ways) expressing the willingness to contribute to the project. Always take a humble and transparent approach, with eagerness to learn and collaborate. Once identified what one can contribute, it's always best to share their intentions, ideas, and approach for it. Sharing early and often helps in building a relationship as well as being mindful with everyone's time."

Let me know if this is something that would make sense as a description for this principle. Also, if this is the style and way we want to describe them.

— Reply to this email directly, view it on GitHub https://github.com/todogroup/todogroup.org/issues/289#issuecomment-1066687795, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAATESWMCIVDNOOANZIX2PDU74RHXANCNFSM5QKLL7QQ . You are receiving this because you commented.Message ID: @.***>

[jlprat]

Thanks Alyssa, Yes "trust" should be put somewhere in there. And we could expand the transparency thing mentioning that one comes from a company.

[winterrocks]

For the transparency one could mention that one is coming from a company/organization and also mention why she/he is looking to contribute to the project.

[DuaneOBrien]

Some of the intent behind Starts Early was to avoid the bad pattern of someone showing up on behalf of an organization with a significant feature and large pull request, only to find out the receiving project wasn't interested. That ends up creating bad feeling for everyone involved, where Start Early can help avoid them by both providing the opportunity for community input, and early signal that the project may not be interested in the feature.

Coming back to the prose, this bad pattern example could provide some "why" beyond just saying that starting with contributions is rarely the best approach.

[jlprat]

Did some rewrite on my initial attempt (in italics the changes made). Feel free to rework the text!

"One might be tempted to start with their contributions (even for the non-code ones) right away, but this is rarely the best approach to establish a good long-lasting relationship with the given Open Source Community. Doing this might have unexpected consequences like spending substantial amount of time and effort on a task that is not needed or wanted. Sometimes it might even come across as trying to force-add a change that is only relevant to a specific newcomer company.

First of all, one must get to know the community: how it works, what are its needs, and how it is governed. Once this is done, one must start engaging with the community (in their desired ways) expressing the willingness to contribute to the project. Always take a humble and transparent approach, with eagerness to learn and collaborate. Disclosing one's affiliation in pro of transparency is always a good approach, and it will help building trust with the rest of the community.

Once identified what one can contribute, it's always best to share their intentions, ideas, and approach for it. Sharing early and often helps in building a trustworthy relationship as well as being mindful with everyone's time."

[DuaneOBrien]

Proposing a stylistic rewrite for Josep's text:

"You might be tempted to start by making contributions right away. This is rarely the best approach to establish a good long-lasting relationship with an Open Source project, and it can sometimes lead to unintended consequences. For example, a project may have already started work on a related feature, or previously discussed a feature and decided not to implement it. If you start making contributions without this context, you risk wasting time and effort on a task that is not needed or wanted. Even worse, if no one on the project knows who you are, it might even come across as trying to force through a change that is only relevant to your employer.

"You can avoid these unintended consequences by following the first principle: Start Early.

"Rather than starting with contributions, start by getting to know the community: how it works, what are its needs, and how it is governed. Engage with the community by joining their preferred discussion channels and talk about the contributions you want to make. Always take a humble and transparent approach. Demonstrate your eagerness to learn and collaborate. Disclose your company affiliation. Build trust with the rest of the community by engaging before you start any work.

"When you talk about any potential contributions, tell the community what this contribution is important to you. Describe the approach you intend to take and the ideas that you have for implementation. Sharing this information early shows the community that you respect their time and respect the community's way of working."

[lucasgonze]

Some thoughts on the larger meaning of this:

Engage with the community early in the process of development. Incorporate feedback at the founding stages of your contribution. Think collaboratively. Use consensus in choosing what to build. Engage early and often.

[cornelius]

See #384 for a draft for the guide based on the input of the issues.

[alice-sowerby]

Closing as all additional input has been received.