| title | description | draft | menu | weight | category | level | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Open Source Stewardship |
Open Source Culture and Stewardship |
false |
|
20 |
lecture |
|
Working at a company in the Protocol Labs Network (PLN) is a fairly unique experience. For many Labbers, your work will often require contributing to one or many open source projects. IPFS, libp2p, Filecoin, Multiformats, IPLD, and others are all projects created and sponsored by the PL Network. Each of these projects is an independent open source project, and each of them has needs and goals that span multiple organizations within and outside the PL Network.
In this talk by Steven & Dietrich, they review some of the customs and best practices involved when becoming a part of an open source community.
{{< youtube GcvGc3pgOT8 >}}
The tricky part in being an employee of a PL Network company, and a member of a project with its own independent goals, is not conflating the two in a way that is harmful to the community. Talking about company-specific endeavors, internal meetings, and events in public repositories or issues can make other community members feel left out, and uninvited.
One way to think about it is to think of yourself as two people, or one person, but with two hats. When you are wearing that libp2p hat, you are not an employee of your Protocol Labs Network company, you are instead an open source contributor to libp2p. While wearing this hat, you are looking out for this project’s best interests, independent of what your PLN obligations are.
This is an annotated version of this Spaceport article
Open async communication enables greater participation, keeps low-priority matters from interrupting high-priority work, and typically leaves a better paper trail.
Though we aim for async comms, sync time is also valuable for bringing multiple parties into agreement, focused problem-solving sessions, and early-stage project formation. Sync time, or synchronous communication, is widely recognized to be face-to-face conversations, or phone and video communications.
In time, this approach to comms builds momentum and enable us to:
- Build and maintain documentation
- Avoid many miscommunications
- Reduce our bus factor
- Make the switch from proprietary to open-source far smoother
The Async Manifesto, spells out many of these principles. Pay particular attention to the following:
- Valuing modern tools and flexible work environments over meetings and office hours
- Embracing flexibility in prioritization over detailed planning
- Creating comprehensive documentation over tribal knowledge
A high-bandwidth bidirectional communication channel is needed, either for brainstorming or decision making, where all relevant and interested parties can be gathered.
Relevant required readings are distributed in advance.
Our goal is to have resources and processes that allow you, as an individual, to feel empowered to find all the answers to the questions you might have. With that said, here are some guidelines for helping you find what you’re looking for.
- Can’t find the doc? Have you read the main resource? Have you done a thorough search of all resources? Well then, you are really out of luck, BUT! you are probably not alone. Instead of pinging someone, consider it a bug, open an issue on GitHub, and let others answer it asynchronously.
- Need to get an answer to something?
- Is it urgent? No? Send an email.
- Does it need to happen in the next 30 minutes? Yes, then ping the person or team on the channel of the respective work stream, not in a DM. It enables others to pick up an urgent item in case the main person is not available.
- If you know that the person is busy, then consider providing hints on how urgent the email is on the subject (i.e., P0 to P4). Also, be okay with writing emails that are one sentence long. Courtesy over conciseness can cost someone time.
Need something done? Create a GitHub issue, do the footwork of getting it to “ready” state, and assign it to someone.
Ideally, you’ll be able to add it to a team’s kanban board and make sure the team members know about it to make sure it will be covered in some team’s regular check-ins.
Need a decision made? Either open an issue or a pull request (PR) on GitHub. Make sure to identify key stakeholders and set a deadline for discussion/decision.
The 4 components of a great asynchronous message
🗣 Enough information to cover all follow-up questions. Don’t let yourself be the victim of an open loop; over-communicate if necessary.
📅 A deadline. When do you need a response by? How urgent is it? Which task is being blocked right now?
🔗 Links, images, and as much supporting material as possible. Again, include screenshots, screencasts, images, etc. – whatever will help illustrate your thoughts. Add these to emails, GitHub comments, posts, etc.
📥 A concrete need. What do you want to get out of the communication? Approval on a task? An asset of some kind? Be extremely clear.
{{< youtube XHyRCTTYBSA >}}