IDEA: Crosspost software contribution guidelines on publiclab.org

[ebarry]

Please describe the problem (or idea)

What problem could this idea solve?

I am inspired by reading @SidharthBansal 's GCI Mentor Guidelines: https://github.com/publiclab/plots2/blob/master/doc/GCI_MENTOR_GUIDELINES.md

Reading these clear guidelines has made me wonder if we have finally arrived at the moment where we can begin to explain the "ladder of participation" that software contributors join through and then learn to create for others to other types of projects in Public Lab, especially hardware. This is a bit of a leap, so let me add some context:

While it's true that we have explained many of these methods broadly here: https://publiclab.org/notes/warren/03-22-2018/libreplanet-talk-sharing-strategies-for-welcoming-newcomers-into-floss-projects-first-timers-only-list-moderation-and-more ...

1) friendliness 2) Codes of Conduct 3) first-timers-only issues 4) welcoming pages 5) social media outreach 6) code modularity 7) ladders of participation 8) continuous integration 9) friendly bots 10) evaluation

... we have not made such a clear step-by-step PR review as now exists thanks to @SidharthBansal for collaboratively managing projects.

What did you expect to see that you didn't?

I see potential for some steps from the PR Review Guidelines portion to be repurposed in part to guide people who are contributing to hardware projects, or perhaps even the "Research Area Reviews" which look holistically at an environmental issue through hardware, software, advocacy, etc. (cc @steviepubliclab). Notice:

• "writing tests" is sort of like explaining, to someone building a physical tool, how each additional component of hardware should work once added correctly. It answers the question, "How do we know we've built it correctly so far?" before going out to collect data
• directing hardware development at "issues" that others have already filed could help "tune" a hardware project to what community researchers are asking for

Please show us where to look

@justinmanley wrote https://publiclab.org/wiki/contributing-to-public-lab-software some years ago, and we could add to this.

Ideas are welcome!

[SidharthBansal]

Nice idea. I think this document needs to be separately prepared on publiclab.org/post. As most of the hardware community is at pl.

[jywarren]

Yeah, agreed, this is cool! Also note strategies and such at https://publiclab.org/software-outreach which cover a lot of this list @ebarry shared.

I'd say two things we did really well in software outreach is built a good foundation community via first-timers-only issues, and then once we had some people who were taking leadership, we've begun to teach people how to /write/ first-timers-only issues. And then grow from there.

I think the PL kits and activities often give people the right material for a first-timer-only experience, like http://publiclab.org/paper-spec -- but don't yet link that to the next step of "helping someone else take the first step" in the same way.

Note a challenging factor is that hardware doesn't always leave a publicly viewable online trace, the way contributing to software does! But posts on Spectral Workbench do, for example, or MapKnitter.

How could we make peoples' MapKnitter experiences friendlier, like FTOs, and then get them to reach out to other new balloon/kite mappers? Similarly with any given hardware project?

On Thu, Oct 4, 2018 at 2:33 PM Liz Barry notifications@github.com wrote:

Please describe the problem (or idea)

What problem could this idea solve?

I am inspired by reading @SidharthBansal https://github.com/SidharthBansal 's GCI Mentor Guidelines:

https://github.com/publiclab/plots2/blob/master/doc/GCI_MENTOR_GUIDELINES.md

Reading these clear guidelines has made me wonder if we have finally arrived at the moment where we can begin to explain the "ladder of participation" that software contributors join through and then learn to create for others to other types of projects in Public Lab, especially hardware. This is a bit of a leap, so let me add some context:

While it's true that we have explained many of these methods broadly here: https://publiclab.org/notes/warren/03-22-2018/libreplanet-talk-sharing-strategies-for-welcoming-newcomers-into-floss-projects-first-timers-only-list-moderation-and-more ...

1. friendliness
2. Codes of Conduct
3. first-timers-only issues
4. welcoming pages
5. social media outreach
6. code modularity
7. ladders of participation
8. continuous integration
9. friendly bots
10. evaluation

... we have not made such a clear step-by-step PR review as now exists thanks to @SidharthBansal https://github.com/SidharthBansal for collaboratively managing projects.

What did you expect to see that you didn't?

I see potential for some steps from the PR Review Guidelines portion to be repurposed in part to guide people who are contributing to hardware projects, or perhaps even the "Research Area Reviews" which look holistically at an environmental issue through hardware, software, advocacy, etc. (cc @steviepubliclab https://github.com/steviepubliclab). Notice:

• "writing tests" is sort of like explaining, to someone building a physical tool, how each additional component of hardware should work once added correctly. It answers the question, "How do we know we've built it correctly so far?" before going out to collect data
• directing hardware development at "issues" that others have already filed could help "tune" a hardware project to what community researchers are asking for

Please show us where to look

@justinmanley https://github.com/justinmanley wrote https://publiclab.org/wiki/contributing-to-public-lab-software some years ago, and we could add to this.

Ideas are welcome!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/publiclab/plots2/issues/3609, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ-qI2zfqv7lVF9DjDpTXP9m84DLIks5uhlRkgaJpZM4XIq91 .