So Iāve been thinking about this for a while but only had in-person conversations with others (or myself hahaā¦) and Iām keen to have a place where these things are written down (if people want to and feel comfy to.
This is about how weāve noticed bias, discrimination, lack of inclusion for being a function that isnāt typically āseenā in OSS and I often categorise this as someone who ādoes not contribute codeā and possible āSomeone who has never contributed codeā
Iām thinking of the kinds of comments I have received when I show up as a designer in OSS. Or the kinds of conversations I am included in as a designer and revealing myself as such.
I expect and remember, conversations from folks who have similar stories as documentarians/technical writers, product managers, community managers and many other functions.
Iām keen to hear more from others on this and see if there is work being done beyond the ones that I think Iām aware of!
Hi! Iām a newbie and this is my first post. I just wanted to thank you for putting this topic out there. Iām glad to see conversation going and curious to see where it goes. I am a non-coder - project coordinator opps type - wanting to transition to tech, esp OSS and/or tech nonprofits. Iāve found it difficult to find entry points into this area (even when considering documenting, technical writing, and community management, too). It just seems like the #s are slanted so highly (eyeballing Iād say 5:1) to engineers, for what I imagine are necessary reasons. Iād love to learn more about functional diversity AND ethnic diversity in these spaces, as Iām both. Are there other places folks gather on the subject?
If thatās not the sort of thing to ask here, no problem and no harm intended. Iām just getting my bearings.
I cannot express how glad folks like you are here and wanting to be part of OSS OSS really needs a diversity of function as an intersection with all the other diversity elements like race, ethnicity, gender etc.
Iām not sure if there are spaces dedicated to this conversation but there was a fantastic discussion at the last Sustain OSS lead by Erin McKean around the good docs project we started to explore this topic and Iāve found the working groups Iāve been a part of with Sustain to be very eager to have this conversation.
Until someone comes into the thread here and points towards an existing space for this I think we can treat this thread as the beginning of such discussions
@hqrshguptq Iām happy to make an anon, protected doc if folks want to describe any information or experiences that they want protected but if you feel good and safe sharing here I would encourage that! Iāll make a riseup etherpadā¦here! https://pad.riseup.net/p/DandIfunction-keep
Some projects are definitely harder to get started in, and itās not always intentional, add on that operators and users often arenāt even aware they are welcomed to contribute and I believe that leads to the higher numbers of (paid and unpaid) developers in many projects.
There are projects that have on-boarding, mentoring, etc. to help get new contributors and I would definitely recommend finding one of those for your first contributions even if itās just to learn how to join a project. I will say knowing people within a project definitely makes joining a little easier even if you are a developer but a good project should welcome you and the contributions you can make.
Iām definitely not a developer and my first contributions were adding tags for translations because friends asked for some help. These days I do documenting and reviewing, some code, and lead groups within communities.
Happy to help get folks started in OSS and answer any questions.
But project governance is still mostly in the hands of those that code and those are also the names that are persisted in much more visible and permanent form (f.e. PHP has a build in function that lists ākey code contributorsā).
While I personally am not part of a marginalized community, I still sometimes cringe a bit that I essentially defined all the key processes in place for PHP governance but my name is only remembered by old time contributors, so my street cred that used to help me get preferential treatment for feature requests on PHP projects is fading over time. But at least I had and still have some. People that organised user groups, write tutorials never get the same visibility and their contributions are forgotten more quickly.
Hi all, iām appreciating the topic a lot as someone who started as a designer and grew into coding, but also as a mentor to new contributors.
I feel we havenāt created space for good design process or onboarding in open source, and the same is probably true for other functions as well. GitHub is not an ideal space, and can invisibilize those kinds of contributions.
Even design tools arenāt well supported/integrated into the work we do at the Public Lab code community, although weāve tried to encourage use of a shared Google presentation for making designs and sharing design components: https://publiclab.org/wiki/ui#Workflow
Thatās probably too far into the weeds for this convo, but just trying to highlight specific ways that such functions donāt have space provided at a structural level.
Also more broadly, I wish for OSS to better celebrate maintenance, facilitation, and other roles which are so often erased as well as gendered. Maybe an interesting reference is this Manifesto for Maintenance Art by Mierle Laderman Ukeles: https://feldmangallery.com/exhibition/manifesto-for-maintenance-art-1969
This is a great topic, thanks for kicking it off @eriolfox.
The numbers are slanted but I might contend on whether it is for necessary reasons! There is a lot of interesting history into the division of labor and valuation of work. For example, did you know that 60-70 years ago, virtually no value was given to software? At that point, the money and emphasis was on hardware, where there were so many different architectures to compile for.
Then architectures begin to standardize in the 1970s, there is little competition in the hardware space, and suddenly software development goes mainstream because it is incentivized in a new way.
All this to say, I exercise some healthy skepticism on whether the ratio is slanted for good reasons or not.
I think mentoring is a key part of improving ādiversity of functionā.
Historically, code contributions are overly represented in open source contributions. Consequentially, I hypothesize there has been more time for a mentorship culture to grow and emerge around code contributions. Think of the role Stack Overflow plays for things like this.
For things like docs, design contributions, and more ānon-engineeringā type tasks in open source, they have been a minority for some time. I think non-engineering teams sometimes get overwhelmed by unsustainable workloads when their work is poorly understood in an organization or project. Not as much time gets devoted to mentorship and on-boarding new contributors, because sometimes the immediate āfireā is getting a next release out the door.
To this end, open source mentorship is a topic I want to explore more in the 2020s. Great add @spotz.
It is interesting to hear this from the PHP community, because it mirrors a lot of my experience working with @riecatnor in Fedora. @riecatnor came up with an amazing acronym that captures some of the ongoing work in Fedora to recognize our contributor community and celebrate what they do.
Maybe @riecatnor would like to share a bit about R.I.S.E.?
I agree @jywarren. Just curiousā¦ what do you think better celebration of these things might look like?
I searched my docs, and found an unpublished blog post that I could snip from. This was a concept/series of ideas I came up with around contributor fulfillment and my own experience as a non-coding contributor to the Fedora Project. The overall idea is that to achieve contributor fulfillment you need RISE (recognition, incentive, support, empowerment). The ideas behind each of the four concepts are by no means inclusive of the different ways these can be provided. It would might be benficial to mindshare RISE with the group and translate our ideas into a general purpose community building resource.
Cheers!
-riecatnor
RISE Initiative
RISE:
Recognition
Incentive
Support
Empowerment
Recognition
Improve and revitalize Fedora Badges (gamification of contributions)
Focus on metrics (can be simple!) and using those to show off what teams are doing. At flock, on community blog, social media. (improve visibility of the work)
Create strong designs to communicate these stories (make it easily consumable & interesting)
Fedora Zine (publication to specifically highlight non-coding roles within Fedora)
Fedora Appreciation Week (peer to peer)
Karma bot & cookies (peer to peer)
Incentive
Focus Flock to Fedora on emphasizing and capitalizing the things it does well. (yearly conference)
Energize people for the year ahead, foster team building
Make sure to provide plenty of time for networking and discussions.
Encourage people to learn by stepping away from the things they already know.
Provide social time that encourages cross team socializing and bonding.
Focus on fun!
Provide more learning and network opportunities (Social hours, classrooms, etc)
Traveling can be an incentive (when possible, of course), but this is a privilege a lot of people canāt normally take advantage of. (new experiences)
Support
Clear paths of communication (good documentation)
Strategy coming from Fedora leadership/Council (Input from leadership flows freely)
Highlight that our community members have access to the above two entities (visibility of leaders)
Make sure it is well known that people can run small events, get funded to go to conferences that are not Flock, etc, propose ideas for swag (good documentation/marketing/blogging)
Empowerment
Go out of our way to invite underrepresented people to voice their opinions on their own terms, i.e. sending a direct email to solicit thoughts on a topic (reaching out to individuals)
Provide spaces in which underrepresented people feel comfortable speaking up (prefacing meetings, providing different modes of communication)
Advertise small events and help contributors to run them (mentorship)
Focus on the Diversity & Inclusion team (enable others to empower)
You mentioned a blog, do you have these published somewhere I can reference? I love this so much, I want to discuss with my fellow OSS maintainers at our next meeting
It is unpublished unfortunately I have talked about RISE at a couple Fedora things, but it hasnāt gone much farther than that. It is something that I personally reference when I am helping the Fedora community with various things. Other things came up, I am sure you know how it goes.
In the future, I envision a Fedora RISE initiative. Sort of a mash up of a marketing plan & community engagement strategy. The idea would be that the teams under our Mindshare umbrella (non coding teams) are specifically aware that we are trying to fulfill these needs, working on improving them, and then actively engage them in improving the contributor experience within the Fedora Project. This initiative should also be applied to the coding teams within Fedora as well. Side note, we have a Badges system, and I was thinking of creating a āRISE Championā Badge to award to members of the community who are helping to forward these goals or exemplify these actions in their work already.
This topic has been near and dear to my heart for a while. Molly de Blanc and I have presented on this topic, both together and separately *. Anyway, I wanted to say to one point made upthread about how coders might be too busy to bring on folks from other disciplines. I do think we often maintain a breakneck, unhealthy speed but I also think maybe coders shouldnāt be overseeing designers, but rather collaborating with them. But even if the FOSS community worked really hard on itās unwillingness to fully delegate things (I have some feelings about this topic too. **) to the people who are good at them and fixed its unrealistic deadline problem, I think weād still have a ānot valuing non-code thingsā problem. Working on these things would help us reach our (hopefully) shared goal of getting people to use, enjoy and recommend our software offerings.
Iād love to find more ways to keep pushing FOSS forward on all fronts!
Deb
Non-Coders Wanted: How to Get and Keep Non-Tehcnical Volunteers
I have talked about RISE at a couple Fedora things, but it hasnāt gone much farther than that. It is something that I personally reference when I am helping the Fedora community with various things. Other things came up, I am sure you know how it goes.