Notes from the Foundation for Public Code community call - 21 January 2020
Attendees
Call topic
In this call, we discussed About issue #762 on how to embrace contributions to our open work in practice.
This built on our October 2020 community call, which focused on building better relations with our community.
We explored these questions:
- What do we want from responding to new input and new contributions?
- How can we build a great professionalism around that?
- What can we do more openly?
We hoped this would also be useful priming before FOSDEM 2021.
Discussion summary
The discussion opened with the observation that Foundation for Public Code staff regularly defaulted to ‘us’ and ‘them’ language, for example in the topic and invitation to this community call, and practiced in-group behavior when editing the Standard. Since these are our collaboration spaces, how could we shift to thinking and speaking about the larger ‘we’ for all our fora?
In practice, almost anything staff do is a contribution to something or someone. Recognizing this, it was logical that the Foundation for Public Code as an open organization would encourage deliberately breaking down any instinctive boundary that staff hold.
Staff regularly contribute to projects they don’t know very well. Based on their experiences, it should be possible to change staff practices to dogfood managing contributions well.
It was proposed that both staff and everyone in the broader Foundation for Public Code community should aim to build a culture of experienced contribution management.
Possible actions
These actions were suggested by call participants:
-
All Foundation for Public Code repositories should list maintainers, or the responsible Foundation for Public Code staff (“the natural team” given roles and expertise), in the governance file
-
All substantive contributions (i.e. not typo fixes) should have a linked issue where discussion takes place to clarify the problem before a pull request is made. This means that people can give detailed feedback on a pull request because the validity and scope of the problem has already been agreed.
-
All contribution replies (including to staff) should follow The Gentle Art of Patch Review priority hierarchy, with an emphasis on deliberately teaching contributors how to best fit their idea into the overall architecture
-
While reviewing, write all contribution feedback on a separate page, and then reorder or edit it to make sure conceptual feedback is given before detailed feedback
- Maintainers can practice giving higher quality feedback, for example by:
- focusing on the quality of the idea or pull request instead of the person making the contribution
- recognizing that negative feedback is inevitably necessary for increasing quality, so framing mistakes as learning and growth opportunities
- Staff should contribute to Foundation for Public Code repositories from their personal Github accounts, rather than via their repo access. This way staff are familiar with the contributing experience of people who don’t have repo access. This also symbolically puts all contributions on equal footing. Since not all staff know how to do this, training needs to be identified.