Page MenuHomePhabricator

GSOC 2017/Outreachy Round 14: Lessons that we are learning along the way
Closed, ResolvedPublic

Description

The task is for the Outreach programs admins and project mentors to share what is working well and what we could improve for the next time. After the current round of programs gets over, the lessons learned will be moved on to a wiki page.

Event Timeline

The application deadline for both GSOC/Outreachy is over, and here are some lessons that we've learned so far and suggestions for improvements for the next round. Sharing notes from in-person conversation w/ @Mooeypoo below:

  • Both program pages on MediaWiki contain a lot of duplicate information, and so it makes sense to have the same page for GSOC/Outreachy. It will be helpful both for the students as well as for the mentors to dig information
  • Examples of good proposals that we've linked are little too ambitious/ overwhelming
  • There should be a quick checklist for things that students need to complete for successfully submitting their application, and this info should be visible to others as well. For example > https://www.mediawiki.org/wiki/Google_Summer_of_Code_2013
  • Information about Microtask was missing from the "Recommended Next Steps" section on the GSOC page
  • The proposals created on Phabricator didn't follow a format that was readable enough, so one of the ideas could be to link application template to a Phabricator task that has a template embedded in it already
  • We need to revise our documents for Outreach programs and be consistent when it comes to sharing links on Phabricator tasks

What worked well?

  • Adding projects on the MW GSOC page itself was helpful
  • Announcement on the She Codes facebook group by @Mooeypoo brought some interest and good applicants for Outreachy. We should consider doing the same, and also post on similar groups

https://www.mediawiki.org/wiki/Outreach_programs/Selection_process#FAQs_for_candidates says, "If your proposal is incomplete or you haven't done any microtasks yet, then we encourage you to work hard and submit microtasks as soon as you can after the deadline." which I think should be clarified with, "Mentors do not have to consider microtasks done after the application deadline" (or similar).

The application deadline for both GSOC/Outreachy is over, and here are some lessons that we've learned so far and suggestions for improvements for the next round. Sharing notes from in-person conversation w/ @Mooeypoo below:

  • Both program pages on MediaWiki contain a lot of duplicate information, and so it makes sense to have the same page for GSOC/Outreachy. It will be helpful both for the students as well as for the mentors to dig information

There are already common pages, mainly https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project . Perhaps we could have very specific and brief Outreachy and GSOC pages, which refer to the common pages. There are some specific requirements for each program (e.g. GSOC applicants must be students, Outreachy has its own eligibility requirements) which need to be covered.

In general, I think all of these pages should be much much shorter.

They should be separated based on phase and audience, which will support brevity. E.g. different parts of https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project are aimed at the pre-application phase, application phase, the actual project phase, and at mentees vs. mentors. Applicants shouldn't need to see "For possible mentors" on the same page.

Similarly, https://www.mediawiki.org/wiki/Outreach_programs/Selection_process is mostly aimed at mentors/administrators, but is partly (the FAQ) aimed at applicants. The part for applicants should be moved elsewhere so we never need to refer applicants to this page.

The old way of listing Outreachy applications on wiki made the hard requirements very clear, example: https://www.mediawiki.org/wiki/Outreachy/Round_8

The table sent a clear visual clue if you were missing any required components (microtask, application, mentors) without involving reading a lot of directions. There were also links to weekly reports/blog posts in there so you could follow along. This was lost in the move to phabricator.

I would almost like to see this table back, although I know it adds an additional burden with students having to add info on the gsoc site, phabricator, and then on wiki as well.

Another complaint I have is how difficult it is to find the hard requirements for outreachy, even on the outreachy page, particularly involving the midterm report. We are asked by outreachy admins to give our input a week before the midterm, which is before our students have necessarily completed their midterm reports. Students should be provided with a hard deadline for their midterm report, and then we should have until the week after to review them. I guess this is a complaint I should make upstream.

An additional idea I have is that we should maybe make it policy to communicate our midterm reports to the org admins as well as the Outreachy/GSoC admins.

@Mvolz & @Mattflaschen-WMF thank for sharing your wonderful ideas!

The old way of listing Outreachy applications on wiki made the hard requirements very clear, example: https://www.mediawiki.org/wiki/Outreachy/Round_8

Yes, exactly the same was shared by Moriel and we'll bring back the table in the next round. For the current rounds as well, after we have the final results, I will add a table, and atleast use it for weekly reports.

An additional idea I have is that we should maybe make it policy to communicate our midterm reports to the org admins as well as the Outreachy/GSoC admins.

Yes, I will try to make sure that we do this in a proper way!

There are already common pages, mainly https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project . Perhaps we could have very specific and brief Outreachy and GSOC pages, which refer to the common pages. There are some specific requirements for each program (e.g. GSOC applicants must be students, Outreachy has its own eligibility requirements) which need to be covered.

In general, I think all of these pages should be much much shorter.

Yes, I'm considering on revising the documentation of our Outreach program pages very soon, and planning on doing it exactly the way you are suggesting :)

Sharing my belated feedback / random impressions:

  • Phabricator "create subtask for your application but set yourself as assignee but remove some tags but add the GSoC or Outreachy tag" workflow is confusing and quite some people failed (or occasionally even created subtasks of proposals being already subtasks).
  • Some applications were poor quality and very vague though we link to good application examples on the wiki. Maybe our expectations need to be more prominent. I needed to link to https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project#Coming_up_with_a_proposal too often. But I don't think we can force people to read through all of our stuff on several subpages.
  • Maybe make it more prominent that we expect a completed microtask to be linked (search for the word "microtask" on our wiki pages and check if it's really mentioned)? (But students also had issues finding microtasks so this might be something for the mentors to our 'advertised' projects: Provide a bunch of small tasks already as part of the 'advertised' project)

From discussion w/ Outreachy coordinator and project mentors:

We should make it clearer in our documentation that it's optional for students to list their personal details on the public version of their application on Phabricator.

Now that the results are announced, a few more things to add here:

  • We had one slot conflict w/ another organization, and there isn't currently any way in the application system for students to specify how many organizations they are applying to, and what is their preference order. Slot allocation is granted on the first come first serve basis. Google doesn't plan to make any changes in their system. However, Stephanie has suggested that we could ask students to indicate their preferences in the application. This might not solve all the problem but help us a lot while resolving slot conflicts w/ another organization and prove our point.
  • We also ran into a major problem at the last moment, where a few of our candidates from the same university almost likely to be accepted were reported as ineligible (by Google) and we were being asked to replace them w/ others in the queue. We're still not sure what happened, as we don't know what the reasons were. We couldn't do much about this, as Google takes care of the verification process. Still, what we could do as org admins and mentors is to try to come up with a system to verify if our incoming students are enrolled in our university, and strongly look for that information while viewing applications. Although, with the students with whom we had issues, had this information precisely indicated on the application.

(But students also had issues finding microtasks so this might be something for the mentors to our 'advertised' projects: Provide a bunch of small tasks already as part of the 'advertised' project)

My understanding is that mentors are already expected/required to do this. https://www.mediawiki.org/wiki/Outreach_programs/Life_of_a_successful_project#Start_working_on_microtasks said "Mentors should ensure there are a combination of easy and not-so-easy open bugs, but never tasks that would take more than, say, a full day of an experienced contributor to fix. micro-tasks. :) [...] If you see that your project task does not have any microtasks listed in its description, you can get more microtasks by:"

I've added "Mentors should list these microtasks in the description of the project task." there.

When the pages are separate by audience (e.g. mentor) and phase, this will be clearer.

srishakatux lowered the priority of this task from High to Low.Jun 27 2017, 2:19 AM

Closing this task, most of the changes suggested by mentors can be seen in action in the outcomes of this task T167065. Mentors and students will soon receive a short program feedback survey.