[OSCTC-planning] integrating project contributions to OSCTC events

Fri Oct 10 15:31:49 UTC 2014

On 09/29/2014 04:05 PM, Shauna Gordon-McKeon wrote:
> Hi everyone,
> 
> I've been having separate discussions with Alex of Growstuff, Jennie,
> Larissa and Emma of Mozilla, and to a smaller extent with maintainers from
> PeerLibrary and OpenMRS about how to integrate their projects into OSCTC
> events.  I thought I'd bring those conversations together and onto a more
> open platform, in the hopes of improving the process as well as providing a
> model of best practices/workflows that others can copy.
> 
> (This got kinda long.  For project maintainers, my specific questions for
> you are: which of the goals below do you feel most enthusiastic about?  For
> those goals, how do you feel about my proposed next actions?  Are there
> actions I don't mention that you think would benefit your project?  Feel
> free to respond quickly, at length, or not at all.  :) )
> 
> I think the first step thing to do is figure out what the goals are for our
> events. Are the goals to:
> 
> A) Enrich attendees' experiences by teaching them specific skills?
> B) Enrich attendees' experiences by giving them the experience of
> contributing to an open source project?
> C) Enrich both attendees' and project maintainers' experiences by
> establishing ongoing relationships?
> D) Enrich project maintainers' experiences by helping them work on their
> newcomer onboarding process?
> E) Enrich project maintainers' experiences by allowing newcomers to
> contribute important changes to their project?
> 
> Obviously these are not exclusive goals, but I think it's useful to keep in
> mind that they sometimes conflict, and that different ways of structuring
> collaboration will promote different goals.  Some thoughts on individual
> goals:
> 
> ### GOAL A: Enrich attendees' experiences by teaching them specific skills
> 
> Because every project has a different design and different needs, it will
> naturally lend itself to teaching different skills. For instance,
> contributors to the OpenHatch website often learn about setting up local
> development environments, as our process is simple enough to be a good
> first exposure to the process.
> 
> By identifying specific skills that are necessary for contributing to a
> specific project, we allow ourselves to more efficiently match projects
> with students who have or wish to gain the specific skills.  We also allow
> ourselves to better define what it is mentors should do at the event, as
> they can prepare to teach those specific skills.
> 
> POTENTIAL NEXT STEPS
> 
> If we choose to focus on this goal, we could:
> 
>   * Come up with a guide or process to help projects identify which skills
> are necessary to contribute to their project.
>   * Ask students to list ahead of time what skills if any they are
> interested in learning, and introduce them to project maintainers where
> there is a match.
>   * Collect resources (perhaps on the OpenHatch wiki) which also teach said
> skills, to support project maintainers in their mentoring.
>   * Select/tag tasks for our event that focus on building those skills.
>   * Run supplementary events (remotely, or on campus where local organizers
> are interested) that are focused on that particular skill.
> 
> ### GOAL B: Enrich attendees' experiences by giving them the experience of
> contributing to an open source project
> 
> This has been one of our ongoing and implicit goals.  I think it's a vital
> one, but it has a few limitations.  For one thing, the experience of
> contributing to a project for a short time, at an event, surrounded by
> mentors is not typical of FLOSS contributions.  I've been working to make
> contribution possible by disappearing common FLOSS problems such as
> difficulty setting up a development environment, providing in-person and
> remote mentors so that asynchronous communication isn't an issue, and
> identifying/creating tasks that have way more information associated with
> them than the average FLOSS issue.
> 
> I don't actually want discussion of the above obstacles to disappear from
> our events, and I've been trying to grow attendees' mental image of
> contribution through projects like MergeStories (<http://mergestories.com/>)
> and by encouraging mentors and career panelists to talk about a diversity
> of experiences.
> 
> But is that the right approach?  Perhaps we should focus instead on
> actively teaching attendees how to deal with these issues.  We can create
> workshop activities that address common obstacles and have attendees work
> through them with the help of mentors.  We've got an example of this
> already (<
> http://openhatch.github.io/open-source-comes-to-campus/lessons/newcomer-tasks/setup/#/>)
> and I think could readily make more. However this leaves little room for
> projects that have done the hard work of making their projects accessible.
> 
> POTENTIAL NEXT STEPS
> 
> If we choose to focus on this goal, we could:
> 
> * When bring a new affiliated project on board, ask them to work through
> improving their onboarding process with students at an event.
> 
> * Ask projects maintainers to identify different kinds of contributions:
> those that can be readily made in a short sprint, and those which require
> ongoing contributions.  For the latter, we could provide more explicit
> instruction about asynchronous communication, community norms with regard
> to expectations and how to follow up, and giving them mental models of what
> contributing looks like.
> 
> * Review our project guide (<http://opensource-events.com/>) and figure out
> which steps are the most important for creating good bite-sized
> contributions for events, so that those can be focused on.
> 
> ### GOAL C: Enrich both attendees' and project maintainers' experiences by
> establishing ongoing relationships
> 
> I am particularly excited about this goal.  While I think it is valuable
> for students just to come to the event or make a single contribution, it is
> also great to see students becoming active members of open source
> communities.
> 
> What are the barriers to this happening?  Obviously many students will
> simply not be interested enough to continue on in FLOSS, but some
> percentage likely are interested.  Potential problems might include: not
> feeling interested in the particular projects they've made connections to
> at an OSCTC event, not feeling like they have enough time, and feeling shy
> or like they can't contribute anything of importance.
> 
> POTENTIAL NEXT STEPS
> 
> If we choose to focus on this goal, we could:
> 
> * To better match students to projects they are interested in, we could
> advertise projects that will be available to work on at the event during
> the sign up process and allow students to contact projects they're
> interested in (or vice versa).  This would be extra work for project
> maintainers but could be opt-in.
> 
> * To help students find the time to contribute, we can actively teach time
> management and communication skills.  We can also make sure to talk about
> funded opportunities to contribute (<
> https://openhatch.org/wiki/Opportunities>).  A third and likely quite
> complicated option would be to reach out to professors at their school and
> ask about what options have to build open source contributions into their
> schoolwork.  A fourth step could be to come up with a template independent
> study proposal for contributing to open source -- for the limited number of
> schools which embrace independent study proposals, this could be a valuable
> resource.
> 
> * To help students with impostor syndrome, we can add an impostor syndrome
> activity at our workshop.  We can also work with projects to identify tasks
> that will help students contribute regularly in meaningful ways.
> 
> ### GOAL D: Enrich project maintainers' experiences by helping them work on
> their newcomer onboarding process
> 
> I think this an area for OSCTC to really shine.  One of the best ways for
> newcomers to help projects is to help them improve their accessibility to
> othe newcomers.  OSCTC events have a lot of newcomers and a lot of projects
> that want to be more accessible to newcomers.  I'm surprised this approach
> wasn't obvious from the start!
> 
> The event activity linked above (<
> http://openhatch.github.io/open-source-comes-to-campus/lessons/newcomer-tasks/setup/#/>)
> is new and aimed at accomplishing this goal.  I don't believe either of the
> events that ran in September used this activity, however.  It may not have
> been appropriate for most of the projects that were at the event - I know
> Mozilla, for instance, has already put a ton of work into their onboarding
> process and may not benefit from this particular activity.  However I think
> it will be quite valuable for some projects and hope to highlight it more
> at future events.
> 
> POTENTIAL NEXT STEPS
> 
> If we choose to focus on this goal, we could:
> 
> * Identify other common onboarding problems and create activities through
> which newcomers could contribute solutions.  For instance, we could come up
> with an activity through which newcomers identify insufficiently documented
> bite-sized tasks, through which newcomers ask questions about cultural and
> community norms that allow maintainers to create a community guide, etc.
> Specific projects may have specific versions of these activities for
> specific onboarding needs.
> 
> ### GOAL E: Enrich project maintainers' experiences by allowing newcomers
> to contribute important changes to their project
> 
> This goal is sort of the complement of B, "Enrich attendees' experiences by
> giving them the experience of contributing to an open source project".
> When I joined OpenHatch over a year and a half ago, we were very focused on
> B + E, and we've continually worked on reaching this goal.  Which is
> understandable: when this works, it's a fantastic feeling for newcomers and
> maintainers alike. However, it's a *hard* goal to achieve in only a few
> hours at a first-time event.  In my experience, students tend to bypass the
> achievable goals - making a doc fix, for instance, or reproducing a bug -
> in favor of code-heavy and ambitious options.
> 
> As I said in my comments on Goal B, I'm not sure if the approach we've been
> taking is the right one.  I do think that if we want students to be able to
> make significant contributions to projects we'll need to focus on building
> ongoing relationships.
> 
> POTENTIAL NEXT STEPS
> 
> If we choose to focus on this goal, we could:
> 
> * Work with projects to identify elements of the projects to which
> newcomers could more easily begin contributing, and focus on them at the
> event.  If these elements require more sustained contributions, we can work
> on facilitating that.
> 
> * Do better expectations-setting with attendees with regard to what they
> can accomplish on which timescales.  I think it's important to validate the
> desire to "really contribute" while also being honest about the hurdles to
> overcome.  Perhaps the answer is to take the meta-conversation we're having
> here, and that we've had on other threads and at conferences etc, and bring
> it into the newcomer event in some way.
> 
> ******
> 
> If you've made it to the end of this email, I'm impressed!
> 
> I'm hoping to get feedback from folks and then draw up a plan of action
> over the next week or two.
> 
> :)
> 
> ~ Shauna
> 
> 
> 
> _______________________________________________
> OSCTC-planning mailing list
> OSCTC-planning at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/osctc-planning

My response is: yes, I think you have laid out a bunch of possibly
conflicting goals and approaches really well, and I don't know what
we/you ought to choose. Perhaps we should really split up *different
kinds of events* and accept a bit of brand/product line fragmentation.

-Sumana

-- 
Sumana Harihareswara
http://www.harihareswara.net/