stories from the Public Lab community
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.
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).
PL follows a 3 step process for initiating new members:
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.
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:
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:
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.
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.
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.
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):
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.
Follow related tags:
software blog code barnstar:basic
For a long time, folks making new pages and interfaces at PublicLab.org have not had much (if any) guidance or direction, and, understandably, have brought their own ideas to the project. This is great initiative, but we could do a better job setting some clear design conventions, and the whole site would benefit from some more consistency.
We're at a point where we could use some input and feedback, so here's a draft!
Our goals include:
This guide won't cover every situation, but will establish an overall approach to UI design that all our work should build on cohesively.
Check out the draft style guide here -- comments and input are very welcome!
We'll be adding more and more annotations as we go, so that it's clear /why/ we've made these recommendations, and how to apply them.
We'll also be following up in a later version with code samples and links to templates!
For developing more complex mockups and prototypes, this may be a great tool!
Follow related tags:
website design blog code
Hi, all! I wanted to reach out because we will have a record-size team this summer, between 2 Outreachy and 13 GSoC fellows --- we've never had a group this big! We also have a bigger mentor group, but we will certainly need students to help one another. I wanted to reach out and welcome everyone, but also set the tone for the kind of mutual support we will need to succeed together.
Here are the announcements - congratulations!!!:
I was thinking of asking people individually to keep an eye on someone else's work even as they do their own. Each person might have a set of skills they could use to help another with -- whether it's writing tests, making FTOs, solving database issues, designing UIs, or creating clear and simple documentation. We'll need to rely on each other --- students helping students above all --- to pull this off and ensure everyone has a great summer, learns a lot, and finds success!
A note to those who we weren't able to accept in this year's program: we had over 20 fantastic proposals, and if we had the slots available and the mentoring team, we would surely have accepted more. Please know that we are extremely grateful for your work with us to date and that we welcome you to continue being part of this community. We considered many factors, among which are the prioritization of different projects, our ability to support different kinds of projects with good mentorship, and much more. So our inability to accept you should not be taken in a discouraging way, or as a suggestion that your proposal and your skills were not impressive and exciting on their own merits. Thank you for understanding and we hope you'll apply again ❤️
|GSoC proposal: Mapknitter Image Management and Synchronous Editing||@divyabaid16||about 1 year ago||1||2|
|SoC proposal: GSoC: Websocket Implementation for Real-time Usage and Sensor data and Display Library||@namangupta||over 1 year ago||4||20|
|SoC Proposal : Spectral Workbench Capture||@sidntrivedi012||over 1 year ago||3||12|
|SOC 2019: A small proposal for global environmental monitoring||@MaggPi||over 1 year ago||1||13|
|GSOC-19 Mapknitter synchronous editing||@vidit||over 1 year ago||0||2|
|SOC proposal: Extend Leaflet Environmental Layers with new layer menu and layer addition workflow||@anan12||over 1 year ago||4||5|
|GSoC proposal: Image Sequencer||@aashnaaashna||over 1 year ago||3||10|
|Outreachy Proposal 2019 For Public Lab:||@gautami_gg||over 1 year ago||5||12|
|GSoC Proposal: Mapknitter Rails 6 upgrade||@kaustubh_nair||over 1 year ago||2||7|
|GSoC proposal: Mapknitter ORB Descriptor (w/ auto-stitching, pattern training, and live video support) and LDI revamp (major UI enhancements)||@rexagod||over 1 year ago||5||35|
|SoC proposal: Community Toolbox overhaul||@icode365||over 1 year ago||2||16|
|SoC proposal: Image-Sequencer v3: Boosting the performance and adding demonstration based on colorimetry||@lit2017001||over 1 year ago||5||7|
|GSoC proposal: Sensor data upload and display library||@IshaGupta18||over 1 year ago||7||34|
|GSoC Proposal 2019: Mapknitter's Rails Upgrade||@alaxallves||over 1 year ago||0||5|
|SoC proposal: Enhancing the UI of publiclab and relevant changes to server||@lekhidugtal||over 1 year ago||8||21||Show more|
Follow related tags:
gsoc blog code soc
Start Date: Mid June 2019
Location: New Orleans, LA
Terms: Full time
The Public Laboratory for Open Technology and Science (Public Lab) is a community-- supported by a 501(c)(3) non-profit--that develops and applies open-source tools to environmental exploration and investigation. By democratizing inexpensive and accessible Do-It-Yourself techniques, Public Lab creates a collaborative network of practitioners who actively re-imagine the human relationship with the environment.
This position is based in New Orleans and will be responsible for managing the business and operations of the Public Lab nonprofit. Day-to-day tasks include bookkeeping and financial management, supporting human resources and keeping a multi-office, remote team organized through meeting coordination and internal staff communications. The goal of this position is to improve and maintain efficiency and productivity of the organization, and to oversee the management and coordination of fiscal activities for Public Lab. This position reports directly to the Executive Director.
Major Position Responsibilities
A Bachelor's degree or equivalent in finance, business or other related field is preferred and 3-5 years of demonstrated job experience in a related field is required.
Additional Preferred Qualifications:
Skills, Knowledge, and Characteristics Required
Compensation is between $40,000-$50,000, based on experience and qualifications. Public Lab offers a benefits package that includes four weeks starting vacation time in addition to federal holidays and personal days, 75% coverage of health benefits, a 401k and paid sabbaticals. This job requires occasional travel and work outside regular business hours.
Please send a single document containing a cover letter and resume to firstname.lastname@example.org by May 19, 2019. No phone calls please.
Public Lab is an equal opportunity employer committed to a diverse, multicultural work environment. We encourage people with different ability sets, people of color, and people of diverse sexual orientations, gender expressions and identities to apply.
Follow related tags:
nonprofit blog jobs
Jan-Mar 2018: This year we have been buoyed by the growing size of our community and have turned towards larger projects on a year-round cycle, supported by funds from a variety of grants and fellowship programs. Our overall goal this year is to reduce the technical overhead of maintaining systems, and build a sustainable community leadership team that can carry these projects forward responsibly in a more distributed way.
This is "applications season" for our outreach programs, and we've seen a huge response this year (#call-for-proposals), and many applicants for summer fellowships who have already been engaged in our community for months.
We've worked to improve and expand community facilitation and mutual support, as well as build on our commitment to diversity and equity in our work by supporting and encouraging a leadership group with strong representation by groups traditionally excluded in technology development; for the first time, a substantial proportion of our community leaders are women, and greater gender and racial diversity is reflected throughout our community. Our 2019 Software Contributors Survey helped us to better understand both our demographics how our approach to welcoming has worked.
Our community survey shows that ~33% of respondents identify as female or non-binary, which compares favorably with OpenSourceSurvey.org's report that only 4% of the broader open source community are identifying so. In addition, 87% of our community identify as non-white. (cited from our Software Contributors Survey)
We hope that the rich results from this survey can help us to improve even more, and look forward to the deep discussions and plans that will come out of this new information.
With support from Google's Office of Open Source, we are in the middle of a major, months-long project to rebuild and restructure the MapKnitter website and mapmaking toolkit. This has been a great opportunity to build out our leadership team, with five fellows leading projects which engage newcomers while solving substantial technical problems. We hope to begin public testing of the new systems in May.
In the next quarter, we will see a substantial reboot of the MapKnitter project, expansion of the Image Sequencer system (including a colorimetry app), implementation of major UI redesigns, and much more. Thanks to everyone who's helped make this a great quarter for Public Lab software!
Follow related tags:
website web-development software outreach
Logo above courtesy of Pat Popple
Back in September, a number of people from around the Midwest who are fighting frac sand mining issues hosted a couple check in meetings on how things were going, sharing notes on some projects to date (you can read about the conversations here and here). We also had an opportunity to loop in on pathways forward people were seeing that were new, or could use some more attention.
I want to post an update on one of the projects that came up in those September conversations. With support from a number of groups and individuals, we've started to work on the Sentinel Program, originally conceived of by @Pat. This project is aimed at making reporting suspected violations from the frac sand mining industry easier to do.
So far on this project we have:
I wanted to share out the materials so far, and am looking for edits, ideas, and further suggestions. You can comment below or in the doc itself here. We'll also be going over some of this material at the event on Saturday in Arcadia.
Follow related tags:
wisconsin blog frac-sand pm