[OSCTC-planning] integrating project contributions to OSCTC events
Heidi Ellis
ellis at wne.edu
Sat Oct 11 21:23:22 UTC 2014
+1
Heidi
-----Original Message-----
From: OSCTC-planning [mailto:osctc-planning-bounces at lists.openhatch.org] On Behalf Of Sumana Harihareswara
Sent: Friday, October 10, 2014 11:32 AM
To: Planning for Open Source Comes to Campus
Cc: Alex Bayley; Jennie Rose Halperin; Emma Irwin; Larissa Shapiro
Subject: Re: [OSCTC-planning] integrating project contributions to OSCTC events
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/newcome
> r-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/newcome
> r-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/
_______________________________________________
OSCTC-planning mailing list
OSCTC-planning at lists.openhatch.org
http://lists.openhatch.org/mailman/listinfo/osctc-planning
More information about the OSCTC-planning
mailing list