Hi Joel, Thank you for sharing your thoughts. I completely agree that every FOSS project needs docs to onramp users & contributors. I wonder if we can be even more proactive about drawing people into the community, rather than waiting for them to decide that they’re interested. My sense is that many people use FOSS but have no knowledge of the community, beyond maybe knowing that it exists.
I think about college & university alumni relations offices, and how they work hard to engage recent alums, even in small ways, to keep them connected to the institution, so they are more likely to contribute (money or other resources) years later. +1 to patterns! Clif --- Clif Kussmaul <mailto:c...@kussmaul.org> c...@kussmaul.org <http://kussmaul.org/> http://kussmaul.org +1-484-893-0255 EDT=GMT-5 (he/him) From: Joel Sherrill [mailto:joel.sherr...@gmail.com] Sent: Saturday, April 27, 2019 4:22 PM To: Clif Kussmaul <clifkussm...@gmail.com> Cc: tos <tos@teachingopensource.org> Subject: Re: [TOS] any interest in activities to introduce FOSS projects? On Sat, Apr 27, 2019, 11:32 AM Clif Kussmaul <clifkussm...@gmail.com <mailto:clifkussm...@gmail.com> > wrote: Hi everyone, A year or so ago, I went to a library open house where students and faculty demoed FOSS tools like Audacity, FreeMind, Inkscape, GIMP, & WordPress. However, no one I talked to had participated in their project’s community. This seems like a missed opportunity, especially for someone who uses one project heavily (e.g. a musician who uses MuseScore, a designer who uses InkScape). Thus, I’d like to develop some activities to help non-technical people learn more about a specific FOSS project, and how to access it’s online resources and interact with the community. I plan to start with Audacity & MuseScore. Please let me know if you have other project suggestions, or would like to work together on such activities. My hope is that after the first few we can create a template to make it easier to do more. I'm the project lead for RTEMS.org which is a free real-time operating system. Our users are primarily technical but we do end up with experienced developers a d students who have no embedded cross development experience. With that background, every open source project needs documentation to market the project to find these potential users, on-ramp them from different backgrounds and skills levels, and introduce them to the project resources. There also needs to be comparable documentation for on-ramping contributors like developers, patch submitters, documentation fixes, etc. Some of the projects you mention have been Google Summer of Code participants so should have some new developer focused content. Personally I like patterns. If you are looking across a set of projects like it sounds, define roles and what should be in place. Including a suggestion on organisation of it all and artifact names. This could develop into a standard model and that would help new users and open source organisations since they would have a roadmap. Remember every document should have a well-defined audience and scope. Some of the documents may be related to the business cases associated with using the software. A standard I work with has a business and technical side to ensure there business barriers to adoption are addressed. That's just random thoughts. --joel
_______________________________________________ tos mailing list tos@teachingopensource.org http://lists.teachingopensource.org/mailman/listinfo/tos TOS website: http://teachingopensource.org/
