Public Lab Research note


Public Lab's contribution framework (deep dive 2019)

by sashadev-sky | May 16, 2019 16:18 | 195 views | 36 comments | #19429 | 195 views | 36 comments | #19429 16 May 16:18

Read more: publiclab.org/n/19429


sashadev-sky was awarded the Basic Barnstar by warren for their work in this research note.


7 Months

I recently reached my 7th month as a contributor to Public Lab's open source software, a milestone that, amongst other things, brought to my attention that it's now or never to write a blog post.

In the spirit of writing about something that really does deserve a full 7 months of consideration, and still keeps me thinking, I want to shine light on Public Lab's contribution framework.

Open source communities are fascinating to think about because they come in all shapes and sizes - most successful communities share certain commonalities (ie. often called "best practices"), but underneath that their foundations are a testament to achieving a specific ethos and set of goals.

Thinking about Public Lab's contribution framework, founded on 3 simple steps, has allowed me to shape my understanding of the all-encompassing open source community, and what makes Public Lab's sub-community so special.

FTOs

My first PR ever was Oct. 16th, 2018, where I completed what is known in some beginner-friendly OSS communities as an "FTO" (First Timers Only) issue. The labels we use for these, which you might find across Github, are "first-timers-only" and "good first issue". To this day, I have opened 21 of these issues myself.

FTO issues are the glue that holds PL's framework together, and teach us invaluable lessons about open source community and culture. (More on this later).


Workflow

PL follows a 3 step process for initiating new members:

  1. A new contributor completes a guided "FTO" issue
  2. Then they complete any regular issue, often labeled "help wanted"
  3. Lastly, they open their own FTO and help guide a new contributor through it

these 3 steps are incredibly well thought out.


Primer - Openness

One of the most admirable and celebrated aspects of open source is the various acts of kindness amongst contributors in a community. Open source communities make learning an inherently social process, so contributors share an interest in mutual aid and interaction.

Although socialization is inherent, communities still bear the responsibility to facilitate an optimal environment for it. The foundation a community lays down for workflow and culture shapes contributors' interactions.

Public Lab's approach works on the principle of openness. Openness as a paradigm of organization:



This: Openness is an overarching concept or philosophy that is characterized by an emphasis on transparency and free, unrestricted access to knowledge and information, as well as collaborative or cooperative management and decision-making rather than a central authority. More at Wikipedia

Includes this (open source software): 4. computing degree of accessibility to view, use, and modify computer code in a shared environment with legal rights generally held in common and preventing proprietary restrictions on the right of others to continue viewing, using, modifying and sharing that code.



But also openness as a community mantra (ie. receptiveness, kindness, patience).

As the landscape of open source software changes rapidly, with more users joining Github in 2018 than in its first 6 years combined, some communities lead the way in developing a new collaborative model for this uncharted territory.

PL's workflow is exemplary of how this is done. Its approach is multi-faceted, but the focus here is on its ability to cleverly weave community values into its foundational workflow, which carries the most palpable benefits.

Its workflow is a cycle of reciprocity, in which every contributor experiences both ends. From a contributor's first contribution, an air of gratitude starts spreading which they'll carry on.

This is summarized well by the wise words of Google's Summer of Code mentor guide:

"Consider treating every patch like it is a gift. Being grateful is good for both the giver and the receiver, and invigorates the cycle of virtuous giving"

This cycle starts with step 1.


Step 1

provides the opportunity to learn about PL's community culture firsthand while working through an FTO guided by another contributor. This can often be a contributor's first pull request ever, which is one of the toughest milestones in contributing to OSS. Two notable ways PL empowers contributors through its culture of kindness and gratitude:

  • Welcome bot: each new contributor receives a congratulatory message on their first PR:

image description

  • Every FTO receives feedback from reviewers or maintainers. Commenting something as small as "thank you" makes an impact. Surprisingly, this is not necessarily standard etiquette across open source communities.


A quick anecdote: featuring a community that suffers from the absence of any structured empowerment system

Recently, I stumbled upon some incorrectly translated Russian-language configuration files for a platform-specific i18n community. I opened two PRs. Shortly after, they were merged without any communication exchanged besides these notifications:

image description

It's not that I wanted a gold star. My main problem with this was that the process felt like a side conversation with myself rather than a community contribution, which is not a sought after experience in OS.

Communication is an axiomatic part of a community; this is not a revelation. Any communication is good (a merged pull request is a whole lot better than nothing), but not all communication is the same.

Despite having about 400 contributors and 3,500 stars, the repository still has a number of translation inaccuracies that a single, motivated contributor could fix. It is not meeting its full potential because its large contributor pool is not, well, contributing much after a few initial PRs.

Side note: full respect to this community and what they have accomplished. This anecdote only serves to point out the opportunity cost of expending less resources on contributor engagement, and that contributor participation is not something that's guaranteed to a community.



Step 2

provides the opportunity to rinse and repeat the Git workflow learned from the FTO, with the added challenge and opportunity to create and implement self-directed code improvements.


Step 3

creating your own FTO, provides the opportunity to give back to the community - specifically by guiding new contributors through the same process you just worked through recently.

The result is a community in which the contributors are passionate about helping out: see the free response results of PL's contributor survey.

It also creates an atmosphere of mutual support in which contributors experience being both the supported and the supporter. The implications behind this are important. Contributors that make it to the supporter side and open an FTO typically share a common understanding - that every contributor here is challenging themselves to take on new things and grow, regardless of experience level. The prospect of airing one's work in public feels less intimidating within the community. It is completely reframed as a means of connecting to a community, and materializes one of the key benefits of open source: shared knowledge.


Sustainability

PL's community expansion has largely been self-sustainable so far.

As each new member is expected to add at the very least one new FTO, the community grows exponentially.

As cited in PL's 2019 community report:

"we have grown over 400% in the past year to approximately 500 contributors over the total lifetime of the project."

More importantly, contributors proceed to take on leadership roles, such as joining the "reviewers" team, at a pace that reasonably matches growth. A system of distributed responsibility reminiscent of how a blockchain is governed pans out.

Setting a clear path for contributors to be able to advance to the role of a "reviewer" is an important aspect of openness that leads to sustainability, as it creates an incentive for contributors to become more deeply involved in the community. In PL, this path is the completion of the workflow.

These same contributors always go the extra mile. Off the top of my head, projects spearheaded by contributors in the last few months include: a weekly check-in system (implemented by myself and refined by @bsugar), revamping the community contributor page, updating countless documentation to clarify information for newcomers, establishing a monthly open hour call, and most recently - a system for tracking FTOs (by @gauravano, appointed community coordinator).

The benefit of self-sustainability is critical to understanding that the trend towards openness has benefits previously unreachable with an old leadership model (What comes to mind is a repo advertising "New maintainer wanted" on Github after the old network is exhausted):

image description


Open Source in 2019

PL's community growth aligns with a general growth trend in open source. Consider the 2018 Github stats, such as that 1/3 of all pull requests ever were created in 2018.

As more new contributors look for a fit in an open source community on Github than ever before, openness is a useful mantra to follow in 2019 if an organization seeks to inspire new contributors, scale (relatively) organically, and has the flexibility to restructure.

To ensure the consistent application of a community's desired open source practices, this framework for open governance needs to be built on a tailored and well thought out foundation. Public Lab's simple workflow and emphasis on a positive, supportive culture is a great example of how one community approaches structuring their foundation, managing contributor growth and ethos.


35 Comments

Thank you so much for sharing these thoughts Sasha! Also want to note that your editorial and analytical contributions were also important to the Software Contributors Survey Report that you mention. Thanks!

Thank you reading it! Yes I noticed the analytical contributions referencing the Github stats were on the final report... just pulled them right back in here!

Do you see any opportunities for improving this research note? Feel free to co-collaborate on it if you'd like! Right now it just seems a little disorganized to me

But would love your thoughts / input

Is this a question? Click here to post it to the Questions page.


Reply to this comment...


Love this! I wonder if @bsugar or @pdurbin might be interested in this! (although does pdurbin have a PL account? http://github.com/pdurbin)

Is this a question? Click here to post it to the Questions page.

I keep rereading and finding new gems in here. I especially loved this phrase!

featuring a community that suffers from the absence of any structured empowerment system

Amazing! Lol!


And:

It is completely reframed as a means of connecting to a community, and materializes one of the key benefits of open source: shared knowledge.

This was really a great observation. I hadn't thought of that reframing. I think I always underestimate how intimidating it can be to share partially completed work, or mistakes! And this really does try to address that.


Haha! Thank you, I didn't even notice that line honestly. I was too nervous to try to be funny in the post (still haven't reframed in this context), but grateful that dry humor pulled through a bit.

Question: do people get notified every time I edit this?

Is this a question? Click here to post it to the Questions page.


No. We don't send notifications for the node or comment editing.


Reply to this comment...


So, just recapping from a brief chat on this with @sashadev-sky today -- I'd LOVE to try to think of a name for this set of practices. Kind of like how people say "we work in an Agile style" -- what do people say if they want to work in a welcoming way with these strategies? I've brainstormed a bunch but nothing much good's come up: "Welcoming style" "Community-centric development"?

@bansal_sidharth2996 @gauravano @cess what do you think?

Is this a question? Click here to post it to the Questions page.

@warren I was so excited about brainstorming on this on the phone and totally left out why - back in school I did some consulting for an organization, Open4Definition. They've been running decades of research on --- creating the perfect name. (or as they more formally put it, "unlocking the latent power behind behavioral definitions"). They provide services to socially-oriented organizations to innovate behavioral definitions that influence positive social behavior and have the potential to spread.

Think like, "go green", "designated driver", "agile development" (as you mentioned), even "open source"

Their mission statement is definitely idiosyncratic, but I feel like it would be cool to try out for PL's workflow. Going to brainstorm on my own for a bit and then probably reach out to them to catch up and for advice!

What are your thoughts on this idea?

Is this a question? Click here to post it to the Questions page.


Oh very interesting! I'm definitely curious!


Reply to this comment...


This is really awesome Sasha. I really loved your post. It will better to have it in form of wiki pages instead of research pages. We don't want comments under these docs I guess.

@bansal_sidharth2996, can you say a bit more about why we wouldn't want comments under the pages? I like the feedback and discussion about it. Of course, you can leave comments on a wikipage when you click on the talk bubble that leads to /wiki/page_name/comments, but it's a bit more hidden.

Is this a question? Click here to post it to the Questions page.


These comments makes the page too long in the future. So, in future people will have trouble loading long pages in terms of time. We can have the hidden comments options then this will be better. Good idea


@bansal_sidharth2996 I feel like I am not done with it yet anyways. Should I keep working on it here then when I feel like it's done move it into a wiki? This could be a place where people make editing suggestions!

Is this a question? Click here to post it to the Questions page.


Agree with @bsugar's comment -

"when you click on the talk bubble that leads to /wiki/page_name/comments, but it's a bit more hidden."

We have started a major UI improvement project this summer, so we'll surely consider this. Thanks!


Reply to this comment...


Awesome post, Sasha. Really loved it 🎉 . I can relate to your reference to the rails-i18n community. I have contributed and observed some other communities, and yes, practices differ everywhere and I agree that a word of appreciation can make a difference -- the new contributor can become a member and what not 😃 .

shhh I was trying not to out the community in my anecdote! I guess it's pretty obvious to some people.

Anyway thank you for the feedback :) Do you have any notes you share with me about communities that stood out to you (bad or good)?

Is this a question? Click here to post it to the Questions page.


I think it would be wrong to characterize community as "good" or "bad", as the community consists of multiple contributors, members.

Your experience was not good with a particular community, maybe due to the nature of the Russian language moderator?

I have gone through Mozilla's welcoming process(docs only), they really have nice processes in place like having the first issue through Twitter, first-timer tool like ours.

My short interaction(1 issue solving) with all other communities like Hasura, nexmo, etc was also good. I opened a issue at Codingcoach sometime ago, and they were pretty interactive in the process.

I started my Open Source journey with Public Lab and the welcome I got here is unbeatable(@warren didn't give up on me during my first PR and told me about my silly mistakes in the nicest way). So, I enjoy and learn here.

When I think of the improvement scope at PL, some things do come to mind like delay in getting a review, Inactive issues/PRs, Unclaimed/inactive FTOs, so all related to issue and time management. But, we'll work on these and solve them.

(I am trying to make the window for trying Probot on my repo for realizing it's potential but need some push so if someone wants to collaborate, we can bring some major improvement)

Thanks!

Is this a question? Click here to post it to the Questions page.


Woops sorry! I didn't mean the community is good or bad. Was referring more to structural idiosyncrasies that either were + or -.

Would you say I was unfairly critical in my anecdote? I was a little worried about that from the start. I did do my research, though, and there is one maintainer for the entire thing -- assuming he doesn't speak every language and there's a system of trust or some other review process in place we don't see.

Also, I think you'd remember be than me but there were people working specifically on bots in PL. Have you connected with them about it?

Is this a question? Click here to post it to the Questions page.


Your anecdote is fine and I think you've expressed your experience in the nicest way possible.

Oh, I remember @Harshithpabbati brainstorming and trying multiple bots. I should drop a word in the old issue. Thanks for the tip!


Reply to this comment...


Some how I was not notified about this even though @warren included me. I found it by accident on chat, but Jeff is right, I am very interested in this.

@sashadev-sky, this is a really really great article. Can't express how necessary this article is. It should be linked to in any welcome bot. I did not know about the third step at all (except generally speaking as something that's good to do). Still, my experience has been that after your FTO, you're a bit lost at what to do next. This answers the question of how people take on another issue, but still make sure they have support.

@warren, there is a method the wording of which we can play off of from medicine and modify since we're doing it slightly out of order. It's called "see one, teach one, do one". This article explains its rationale, history, and benefits well.

I guess our model is more "do one, do another, support one". I don't think the first one is quite "do one" though. There's something about an FTO which is "do one" but has something extra to it. So I would say we need to fill in the blank with the following:

" blank one, do one, support one"

Maybe...

"Try one, be supported by someone, do one, support someone" "Try one, be supported by someone, do one, create one, support one." "Find one, try one, do one, create one, support one."

I'll think on it.

Something I might have mentioned in the call is that it might be good to have a multi-tired support network. Maybe after completing your FTO, when a new person needs support, you are part of the first group that is notified. If you can't figure out the problem, then you can escalate it to more experienced people. It's sort of an FTO for learning how to support an FTO.

As an aside, I'm not sure if the "read more" link is auto-generated or if you put it there but the "read more" link is the link to this page.

Enter, Inventor, Mentor


I liked it 😃. Maybe, we can try to make it sound more similar to roles like "First-timer, Inventor, Mentor" --> "First-timer, Contributor, Mentor". Nah, changed ones are not that good :P


@cfastie fire emojis did you come up with this? I think this is a good description for the individual steps, rather than the workflow as a whole. Check my updated Step headings :)

@gauravano @warren what do you think of keeping this? Also side note sometimes I go on photoshop binges... is the cartoon repo distracting or a positive addition?

Is this a question? Click here to post it to the Questions page.


@bsugar I just read about an OS model that sounds similar to the multi-tiered system you are referring to (by principle). Its called "the onion model" check it out if you're interested!


I like the cartoon of the repo. How about putting a smile on its face 🙈 ?

Is this a question? Click here to post it to the Questions page.


@gauravano it's jaded because its face is covered by a 'maintainers wanted' advertisement!


Reply to this comment...


Wow! love the post @sashadev-sky, its a really great post 🎉 🎉 (I think I have reread it like 3 times 😃 ) and I really relate to everything you say. @warren I can't think of a better name, words that come to mind are "friendly", "involving", "welcoming", "open collaborative development". Love the "community-centric development" name really good.

Another I saw Sasha use a lot is "gratitude" and it really resonated with me. I had never thought about it in that way but a lot of our approach has to do with expressing true gratitude towards people. So, maybe "gratitude based collaboration" or something???

Is this a question? Click here to post it to the Questions page.


"cycle of virtuous giving" quote I took out of google mentor guide. Probably a little too intense but something to springboard off of maybe? Like something about it being cyclical

Is this a question? Click here to post it to the Questions page.


Reply to this comment...


Wow this is awesome , great analysis !!!

I wish we can pin this note as we do it on github 😃 .

:-) hopefully soon! I solved the first part of this issue and it's ready to be applied to other grids too!

https://github.com/publiclab/plots2/issues/766


Reply to this comment...


Hi @sagarpreet, we have just made this the latest blog post, so it is now "pinned" to the dashboard :)

Reply to this comment...


@warren awards a barnstar to sashadev-sky for their awesome contribution!

Reply to this comment...


Hi, all! I just posted a draft Software Roadmap, which I'd love input on! https://publiclab.org/notes/warren/05-22-2019/draft-of-a-public-lab-software-roadmap-comments-welcome 🙌

Reply to this comment...


Login to comment.

Public Lab is open for anyone and will always be free. By signing up you'll join a diverse group of community researchers and tap into a lot of grassroots expertise.

Sign up