[OSCTC-planning] integrating project contributions to OSCTC events

[Shauna Gordon-McKeon]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20140929/7f90dbeb/attachment.html>