[OSCTC-planning] integrating project contributions to OSCTC events

[Emma Irwin]

Hi Shauna,

My responses inline.

On Mon, Sep 29, 2014 at 1:05 PM, Shauna Gordon-McKeon <shaunagm at gmail.com>
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.
>

I think there is some value in  highlighting the skillset of the intended
contributor for contribution pathways / workflows, and what types of
contribution that group can be successful in lending.  So students, may
indeed help build pathways, but it's unlikely they'll solve any major bugs,
or hack a feature request during an event.

>
> (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?  +1
> B) Enrich attendees' experiences by giving them the experience of
> contributing to an open source project?  +1
> C) Enrich both attendees' and project maintainers' experiences by
> establishing ongoing relationships? +1
> D) Enrich project maintainers' experiences by helping them work on their
> newcomer onboarding process? +1
> E) Enrich project maintainers' experiences by allowing newcomers to
> contribute important changes to their project?  I think if newcomers are
> students, this is overly ambitious.
>
> 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.
>

I think even the generic teaching of skills has a greater scope than just
students.  At SocialCoding4Good I work with amazing, experienced C#, .NET -
etc who experience the barrior or things like github, IRC.    I send them
to Open Hatch all the time  to get those skills first.

>
> 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.
>
Happy to collaborate on this

>   * 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.
>
Most open projects are already so stretched, that being handed list of
students who are interested in contributing - is more work, and not really
help. They don't have time to do the contributor sorting, matching - deal
with people who aren't really committed, who start and backout.... somehow
I think it would be good to leverage the 'training mission' module to track
and identify contributors worth investing in. If that makes sense - I'm
just brainstorming.

>   * Collect resources (perhaps on the OpenHatch wiki) which also teach
> said skills, to support project maintainers in their mentoring.
>
Any chance there could be live/hangout in-person types of training?  I
think that speaks to the isolation of learning on your own.

>   * 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.
>
yes
>
> ### 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.
>

Sorry burning out here - will respond more later.

>
> 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
>
>
>


-- 
Emma Irwin
@sunnydeveloper
Mozilla Reps Council Member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20140930/a3c7fc11/attachment.html>