Grants:Project/Rapid/ROSEdu/Wikimedia Challenge/Report
- Report accepted
- To read the approved grant submission describing the plan for this project, please visit Grants:Project/Rapid/ROSEdu/Wikimedia Challenge.
- You may still comment on this report on its discussion page, or visit the discussion page to read the discussion about this report.
- You are welcome to Email rapidgrants at wikimedia dot org at any time if you have questions or concerns about this report.
Goals
[edit]Did you meet your goals? Are you happy with how the project went?
Unfortunately we were very far from our project goals. The participation was very, very low and this caused the number of patches and merged changes to be equally low. We identified the following causes for the low participation (in decreasing order of importance):
- Low involvement from organizers. Due to different issues, the organizers were much less involved than expected. We were also unable to leverage our contacts in the developers' world, as none of us is a web developer. Insufficient promotion meant the target audience did not hear about the contest in the early stages. A late change in the partner's management gave us a participation surge and got us slightly closer to the targets.
- High entry barriers: it takes the better part of an hour to have a development environment for MediaWiki and several dozens of minutes for Pywikibot and the Android app. None of the installations went flawlessly. This likely meant that we had no remote participants - everybody had to come to a hackathon to setup their environment.
- No clear long-term benefit for participants by contributing. Unlike, say, patches to the Linux kernel, contributing to Wikimedia projects helps little in getting an internship or a job in Romania. Wikimedia software development is little known and is basically relegated to "other contributions" by potential employers.
- Concentrating on the students as an audience meant that we had to match their schedule and caused organizing issues.
- Ability to identify approachable bugs. We tried to use the "easy" keyword as a starting point, but some projects quickly ran out of such bugs or, in some cases, they had a long discussion with no consensus about the approach to take. I tried to steer the participants away from such bugs, but was not always successful.
Outcome
[edit]Please report on your original project targets.
Target outcome | Achieved outcome | Explanation |
25 people submitting at least a patch for review | 7 | Low participation in the hackathons is to blame. Every participant has submitted at least a patch, 4 of them had several patches |
25 patches merged | 7 | Same as above. Please note that the ratio between number of participants and patches merged was kept |
20 participants per hackathon | 3 | See the general conclusions |
Learning
[edit]Projects do not always go according to plan. Sharing what you learned can help you and others plan similar projects in the future. Help the movement learn from your experience by answering the following questions:
- What worked well?
- The work with the participants went very well. None of them left the hackathon without having at least one patch submitted.
- Also, the Wikimedia community's response has been very good. We received responses on IRC almost instantly and all but one of the reviews were started in 1 working day after they were submitted.
- The ratio between users, patches and merged patches was more or less as expected, which means that our expectations on how the work will unfold were realistic.
- What did not work so well?
- Promotion did not work well at all. While we did post through all publicly available channels, the message reached very few students, presumably due to confusing messages (it was unclear what Wikimedia development means). We also did not leverage enough non-public channels (university mailing lists, word-to-mouth etc)
- Scheduling issues meant that we were competing for our audience with other events happening in the same weekend. A better distribution of the events throughout the semester would have helped.
- What would you do differently next time?
- I would not start such a project without having a web developer in the team (both for promoting the event in specialized circles and helping with mentorship). While I did plan to recruit one this time, I was unable to convince anyone, but still went ahead with the project.
Finances
[edit]Grant funds spent
[edit]Please describe how much grant money you spent for approved expenses, and tell us what you spent it on.
Item | Ammount | Ammount (RON) | Ammount (USD) |
---|---|---|---|
First Hackathon | 154.81 lei | 154.81 lei | $36.35 |
Second Hackathon | 78.82 lei | 78.82 lei | $18.51 |
Third hackathon | 212.24 lei | 212.24 lei | $49.84 |
First prize (flight to Vienna) | 164.19€ | 742.26 lei | $174.93 |
Second and third prizes | $135.18 | 575.68 lei | $135.18 |
Bank fees | 2x18 lei | 36 lei | $8.44 |
Total | 1799.81 | $423.25 |
Remaining funds
[edit]Do you have any remaining grant funds?
Yes. We will return the money.
Anything else
[edit]Anything else you want to share about your project?