Grants:Project/Rapid/Wiki Education Foundation/AgileVentures experiment/Report
- Report accepted
- To read the approved grant submission describing the plan for this project, please visit Grants:Project/Rapid/Wiki Education Foundation/AgileVentures experiment.
- 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?
We met our primary goal of making improvements to the Wiki Ed and Programs & Events Dashboards, and of giving us a clearer idea of the medium- and long-term potential of continuing to work with the AgileVenture software development community. In short, it probably does not have the potential to dramatically enhance our technical capacity, although it may become a net-positive over time. We plan to continue engaging at a low level with this community, but without further formal collaboration or contracting.
We did not meet the minimum metric for a "minimally successful" project: at least 10 code contributions from 5 different AgileVentures community developers. As of the end of the project period, we saw 8 contributions from 5 people, although some in-progress work started during the project will likely bring the total past 10 in the coming weeks. The project did not materially improve on the rate of development versus what we would have accomplished in the same time period otherwise, and so cannot be considered "highly successful". While first-time contributions generally went well, we have not seen the hoped-for increase in development speed and developer independence as developers get past the initial learning curve. In part, this may be because of the generally slow pace of activity in the AgileVentures community, which is driven primarily by self-paced learning activities.
Among the unanticipated benefits: opportunities to identify and fix pain points in the developer onboarding process for the Dashboard. At this point, our documentation is substantially better, and new developers with basic familiarity with Ruby on Rails can usually get the app up and running pretty easily.
Outcome
[edit]Please report on your original project targets.
| Target outcome | Achieved outcome | Explanation |
| At least 10 code contributions, from 5 different contributors from the AgileVentures community |  1, 2, 3, 4, 5, 6, 7, 8
|
We saw a fairly diverse set of contributions, which generally addressed small but non-trivial bugs and problems with the Dashboard user experience. The volume of contributions was at the low end of what we anticipated. |
| Accomplish significantly more high-priority development than what we would have accomplished otherwise during the grant period. |
|
Time spent defining tasks in additional detail, onboarding new contributors, reviewing and revising code contributions, and planning/managing/implementing the grant likely took more time than it would have taken Sage to do the same work. Although the net cost/benefit is likely to improve over time, during the grant period it did not allow us to accomplish more than we otherwise would have. |
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?
Separately from the contracted project management work itself, the fact that we were setting up a new formal relationship with AgileVentures catalyzed a wave of increased involved from community members at the beginning. The project management work itself has been done well, and it freed us up to focus on the things that required familiarity with Wikipedia and our own codebase (as opposed to more general logistic and meeting planning activities).
- What did not work so well?
The hoped-for influx of new contributors and increased 'stickiness' of the project — getting developers to both get involved and commit to development tasks, and getting them to stick around and continue making commits — has been modest. In particular, it seems that, although much of the community is in European/Asian/African timezones, simply having a point person available during more of the working day in those timezones has not made a major difference.
- What would you do differently next time?
If we were to do this project again, it would be useful to systematically experiment with several different approaches to attracting, onboarding, and retaining new contributors. In particular, activities such as a) asking questions in general help channels; b) talking about the project in general channels; and c) proactively welcoming new community members and advertising the dashboard project seemed to be among the main ways of drawing in contributors — moreso than holding formal meetings to provide community building and onboarding opportunities as we had anticipated. We did these activities in an ad hoc fashion, but did not carefully track them or their results.
On the project planning and finance side, one thing we didn't plan ahead for was the fee for making the payment to AgileVentures. We did this via PayPal, and ended up paying $78.25 in fees on top of the budgeted amount. We should have budgeted for a smaller contract to make room for such fees.
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.
- $2000 — 20 hours of project management support provided by AgileVentures
Remaining funds
[edit]Do you have any remaining grant funds?
None.
Anything else
[edit]Anything else you want to share about your project? Thanks for the opportunity to try this out! Although this particular experiment likely isn't going to lead to a breakthrough in terms of faster/better development of the Dashboard, it provided a lot of practical experience with onboarding new contributors that will be useful for internship projects, similar experiments with other groups of open source volunteer developers, and — hopefully — onboarding of full-developers in the Dashboard's future.