[OSCTC-planning] integrating project contributions to OSCTC events

[Jennie Rose Halperin]

my responses inline below Emma's.

Meta answer: 
Working with Open Hatch and getting the resources to do so is a P1 priority for me and I will fight the good fight to make this an ongoing and fruitful partnership for both of us. I want to also complement the curriculum work that OH is doing with our own curriculum-building work and I want to make sure that we're complementing and not overlapping.

I also want to become clear on how much of this work is in-person at the OSCTC events and how much of this is evangelism work that we can do in our own project presentations (for example, I repped Open Hatch hard at my talk on Cultural Heritage and Open Source Contribution in Atlanta last week) and how much of this is curriculum on the Internet work. I also want to get clear on how much we as a project vs Open Hatch should be doing. Perhaps this is clear and I just want to do all the things because they're all interesting, but I want to find some clarity around what partnership looks like for us and for Open Hatch.

I think that generally there's a lot more work that every project can be doing to make contribution easier, but I also think that this should be something done in conjunction with overall mentoring efforts across a project. One limitation for us in San Francisco was frankly finding contributors and staff who were willing to spend an entire day mentoring (as opposed to what we call the general eat some cake and hang out for a couple of hours events, and even those are hard to find people for sometime!) I'd like to know more about what we can do with in person events and remote mentors and how we can integrate the two. I'd also like to explore how we can ask for a slightly shorter time commitment from mentors. (Half day, for instance.)
I am also trying to get more institutional support for that, but I'm not sure if that will work out.

Another thing that I think will be really helpful is open up "What makes an Open Source Contribution" and include people who are perhaps not CS students (I'm thinking of a test pilot here with the Columbia Digital Humanities Center, which is doing some incredible work teaching development to non-developers) and including all sorts of contributions. One way in which this can happen is to contact free culture clubs and design clubs and try to bring the Open Hatch curriculum to professional schools in things like Library Science and Design and Media.

Question (and I say this as someone with little programming experience but now a bunch of FOSS experience):
It's really hard to get psyched about open source unless the introduction is to the community and not get stuck on setting up an environment, submitting a patch, etc.. In my experience as a person who has taken intro programming courses, asking people to learn a little before they come can be really helpful (though it was a terrible event that I don't recommend to anyone, check out the directions for setting up your computer for PyCamp in Wisconsin. Super clear instructions and everyone was ready before the event: http://tripython.org/boot-camp/pyohio14/prepare). Another example: Lukas asks people to complete the Code Academy Javascript class before coming to Ascend, which I think is not entirely unreasonable. Also, an ongoing relationship is really helpful...  Mentors making themselves super available after a class, but what would be really helpful would be if they would send me tasks we could accomplish together 
A series of steps that people can take before they come that's a nice intro can help people get ready to get involved. I know there is a lot of this already on the website (and Shauna's amazing tutorials, but making these really clear and invite people to really work with them beforehand. If things like this are already going on and I just don't know about it, more power, but I think it can help people be prepared for events.

On another note:
What helps me as a coordinator:
-- Surveys to know what skills students are coming in with
-- Direct asks for functional teams (like: We have 10 students coming in who want to know about QA. Can you help us?)
-- The possibility of remote mentoring
-- Structures for followup (why should student + mentor stay in touch?)
-- Better student to mentor ratio
-- Concise, clear, and non-jargony introduction to Open Source. We got some feedback last time that the introduction to the day was confusing and set things off on the wrong foot. Maybe even a video would be a good way to introduce?  We've been talking about doing that with our team and would probably be able to support.


I really love the idea of working with Professors, setting up independent study curricula, and making it possible to have supportive communities of practice at universities that go further than one day events, but I think that it may look a bit different, and maybe like an OSCTC spin off rather than folding it into that event.

So more answers inline and totally happy to have a hangout soon, but this is my overall general feeling.

Jennie


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

I agree with Emma, and I don't think it's unreasonable to ask students to come slightly prepared for the workshop, whether it's ensuring that their system is set up or whatever else.

>
> (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 +1
> B) Enrich attendees' experiences by giving them the experience of
> contributing to an open source project?  +1 +1
> C) Enrich both attendees' and project maintainers' experiences by
> establishing ongoing relationships? +1 +100
> D) Enrich project maintainers' experiences by helping them work on their
> newcomer onboarding process? +1 +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. +1 (with caveats)
>
> 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.

Agreed. This is why the pre-course survey was really helpful to me as well as the breakdowns in the kind of skills that students had and approximate percentage of the kinds of people who would be there. What was also helpful was an outline of the school's CS curriculum and the year they were in college.

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

I've already done some of this, albeit in a not-super organized fashion. I'd love to help you make this more organized for Mozilla

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

I agree with Emma, and I don't know if this can be done in the course of a workshop. I think that some sort of badge or ladder system could begin to solve for this. It's also helpful (as stated above) to know what parts of your project are looking for what skills and match in that way.

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

+1 to Emma

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

great
>
> ### 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.

I think a combination  of the two is the right approach. While we want to give people the entire experience of contributing and the whole "yay I just contributed!" aspect is definitely part of that.
I also think that for us, picking a series of tasks and then sticking with them is a good approach. eg.) Beginner students get paired with a mentor who will teach them about tools, events, user stories, development cycle, etc.
intermediate: could be paired with a mentor to walk them through intermediate tasks, depending on their interest
advanced/already contributing: challenge them to contribute in a different area, encourage them to mentor others in the room.

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

I think that is reasonable. but may take a lot of training of mentors. Judging from my own difficulty in getting people to show up, I'd worry that projects that don't have training for mentors already set up may not be able to reach this goal.
>
> * 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.

Also reasonable
>
> * 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.

Again, I agree.
>
> ### 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.

The single biggest piece of criticism I heard about the event we participated in was that the mentor to student ratio was too high, making it difficult for them to talk to many of the students. (8:1) I don't know if this means capping events so that the ratio is better or more aggressively recruiting mentors, but we need to think about how we can make that better.
>
> 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.

I like this, but I am part of a big project with a snazzy name and name recognition is big. I would also open up the opportunity to have remote mentors in this case because it will be easier to match expertise to skills.
>
> * 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.

I like all these things A LOT and you are fulfilling my dreams. We could connect with Dietrich Ayala because he does a good deal of work with this.
>
> * 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.

Sure.
>
> ### 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.

I think this is great, and we DEFINITELY have this need.
>
> ### 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.

I think that's very valid.
>



-- 
Emma Irwin
@sunnydeveloper
Mozilla Reps Council Member