Talk:Volunteer coordination and outreach/ECT Feb 2013 quarterly review

to improve

how many people on wikitech-l & on labs-l?

check - has the mood/tone improved?

How to involve the larger Wikimedia community?

Should we specify some things we're not doing?

Talk about LevelUp benefits

What ECT needs next.

Notes

Volunteer coordination and outreach/ECT Feb 2013 quarterly review, Feb 26, 2013

Attendees: Sumana, RobLa, Quim, Andre Klapper, Guillaume Paumier, Erik Moeller, Tomasz, Chris McMahon, Terry, Howie, Philippe, Greg, Chris, JamesF, Tilman Bayer, CT, Ryan Lane, Brandon Harris.

Remote: Siebrand Mazeland

Sumana: goes through https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_2013_quarterly_review

Benefits

https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_2013_quarterly_review#Benefits (no questions so far)

Lessons learned

https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_2013_quarterly_review#Lessons_learned

Erik: how many Groups do we have now? ( https://www.mediawiki.org/wiki/Groups )

Quim: only two, with one more group trying to get approved. Still too few.

Siebrand: I enjoyed the 20% approach.

Sumana: yes, but overall it didn't work for the WMF.

Timeline

https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_2013_quarterly_review#Timeline

Erik: have we talked to LCA about CRM stuff?

Sumana: yes, we have started working on this. Guillaume and Quim are doing it.

Input we're seeking

https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_2013_quarterly_review#Input_we.27re_seeking

Siebrand: Tone on IRC: There are analyzers for tone of IRC traffic. At FOSDEM there was a presentation (https://fosdem.org/2013/schedule/event/assholes/ ) on this by https://fosdem.org/2013/schedule/speaker/donnie_berkholz/ (X.org, Gentoo). You could run the logs through this and get some validation of the feeling that the tone on #mediawiki has improved.

Siebrand: Why groups are important: http://en.wikipedia.org/wiki/Dunbar%27s_number

Questions

About engaging volunteers

Erik: Language team is a good example. Isolating features and building them with standard components (jQuery) and then working together with other communities out of WMF-only projects.

Sumana: Language team, at some extent Ops and Platform Engineering are trying to be part of the larger community. What teams should prioritize this way of working?

Erik: Other teams are willing to go for this type of approach e.g. at Terry's team. VisualEditor are going in this direction.

JamesF: yes, it is essentially ready to be shared with other, non-MW projects. Long term that's our target.

Tfinc: currently our work is Wikimedia-focused, this is how we planned it to be. Apps development is more open to community engagement than MobileFrontend.

Sumana: is it ok to have specific projects identified as "not good for volunteer engagement"? E.g. Sysadmin tasks or Lua might be. I'm ok with this trade-off. I don't like to fight.

Brandon: I can see some projects under features / design where community involvement is in fact discouraged, because the actual outcome is not good and brings us more work. It is tricky, though.

Erik: we must talk with project managers about the projects and development phases when community engagement is useful. And if the answer is sometimes No then this is fine too.

Erik: what are the assumptions behind volunteer Product Management efforts?

Sumana: for WMF there is a benefit to offload some work, especially in areas we can't focus. For the community it is a chance to get involved and influence with priorities.

Howie: do you see things not working?

Rob: Platform Engineering activities have basically no PM. Developers assume that role. Admin tools development was a good example where there many open issues, requirements, stakeholders - needed prioritizing. This is not a focus of PM team but having a volunteer PM was helpful.

https://blog.wikimedia.org/2012/11/21/lead-development-process-product-adviser-manager/  : the goal are to: "track the progress of these improvements; comment on tasks or proposals; reach out to the Wikimedia reader and contributor communities to ask for feedback via wikis, mailing lists, and IRC; help developers see what users’ needs are; and set priorities on bugs and features, thus deciding what developers ought to work on next"

Howie: what about apps / features?

Brandon: Another example where this was missing: LQT.

Sumana: Mobile, Language, Features have PMs. Platform Engineering and Ops don't.

Rob: One issue in the admin tools example was the time commitment needed for the volunteer product manager, who estimated it at 5h/day

Howie: challenging the assumption that volunteer devs need product management

Sumana: talking about Maria & Kozuch

Howie : level of commitment;

Erik: if there's a need for product management in platform, we may need to acknowledge that need and hire someone for it, rather than trying to have volunteers in that role

RobLa: volunteers are super useful in development; it makes sense to extend this model to product development

Sumana: there are different levels: WMF activities with PM, WMF activities with no PM and then non-WMF activities.

Philippe: Seems like a one to one effort, wonder about scalability

Brandon: demoralization; e.g. we have plenty of volunteer designers, but none of their designs will ever land into core

Sumana & Ryan Lane: some people used to say that about code contributions (and still do)

Quim: what ECT can do is identify the good spots and the bad spots, and direct volunteers to the good spots

Siebrand on product management: Product management is quite a weird job. You can't learn it. You usually need large amounts of expeirence and knowledge to know what's important in a field. This makes getting volunteers very hard in my opinion. It's not the same as prioritizing bugs.

Sumana: What about Ops? we don't really have an apprenticeship pipeline for ops

Ryan Lane disagrees and gives examples; talks about https://www.mediawiki.org/wiki/Wikimedia_Labs#Proposals

Erik: what Ops areas are good for contribution?

Sumana: RT is a problem.

Ryan Lane: stuff that is in RT isn't usually stuff that volunteers are able to do. The majority of the things can be done through Puppet changes without having to give direct access to production servers.

Ryan: the biggest blocker for volunteer participation to ops stuff is configuration that isn't puppetized

RobLa: we've hired a lot of people in recent years but we're not going to be able to keep up with that rhythm, so we're going to need to get back to involving volunteers

Ryan: and approach to ops tasks could be to hire contractors short term to bring projects to Labs, and then rely on volunteers for the maintenance, since that is the big part of the work.

((Engaging designers))

Brandon talking about how it's difficult for designers to have their ideas implemented in production

Ryan Lane: perhaps they could start on other wikis, not en.wikipedia, to meet less resistance and showcase their work

Siebrand: Even though contributing to design may be hard, we could identify processes that would have a higher chance of being succesul. I could imagine that (a) identifying problem areas and (b) allowing a "prototyping area" for these problem areas, and regular IRC or Hangouts about prototyping areas that have plenty of material, will have a higher chance of success than the accidental contributor that thinks they have a solution for some problem. I.e. "best practices".

Howie: ECT could help set expectations about what volunteer designers can do, and the level of quality that we expect

Quim:

Sumana: entry point is mismanaged

Quim: we don't agree about where we should send people, why, etc. => we need to agree on what needs to be done before discussing further

Erik: Need to think about the information architecture for these entry points. Eg. Labs, mediawiki.org

Quim: We have been working on a first general entry - https://www.mediawiki.org/wiki/How_to_contribute . Now we need to work on each of those destinations.

Discussion about project documentation, merging wikis, where to host activity pages & doc, etc.: We need to decide ONE wiki (wikitech.wm.o :-), and stick to it.

Erik: ECT must come in the next quarter with an information architecture to structure all the technical volunteer engagement.

Engineering communications

Tomasz wants analytics

Tilman: we have a problem with setting up analytics on the blog, but the comms team did a survey

60% of readers say they edit

tech blog posts are by far the most important & popular topics

65% say "Information about new and upcoming software for our users" is "very important", 39% "somewhat important"

JamesF sends regular updates (fortnightly release notes) to wikitech-ambassadors. Very high level info, very informative and understandable. (Thank you. :-)) These lead to a bunch of positive feedback from Wikimedia community; from the blog posts we get much less from the community, but some from non-Wikimedian readers.

Siebrand: I want to remark that I'd like to have better release notes for our bi-weekly releases, and preferably also allow for translation of them... But at least send them to the wikitech-ambassadors.

Bi-weekly release notes have been translatable for a few weeks at least; improving the release notes themselves is on Greg's and Guillaume's radar

Erik: various channels...Some stuff advertises itself to outside, for some need to work with Jay and Matthew. Echo will be very important for stuff like the reports

James: Problem with e.g. global message delivery (EdwardsBot): 2-way communication

Erik: Wikitech ambassadors list's growth strategy? -- https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors : This mailing list is used to disseminate information and share experiences regarding large-scale technology deployments in Wikimedia projects. Anyone can sign up to be a "wikitech ambassador" in order to help with this process.

Guillaume: growing wikitech-ambassadors. (Still experimenting on the right model to reach out within the community). We have started translating the summary of the Engineering Monthly reports, the how-to-report-a-bug steps, the How to contribute page

Sumana: How might LCA's community advocates figure into that?

Philippe: Interested in integrating this from beginning

Terry: blog posts language requires to be less-technical. Is there a way to publish mre technical posts, in this or in other blog?

Guillaume: that is possible.' and encouraged, but apparently we need to be clearer about the fact that it is :)

Tilman: we are going to redesign the blog. Not all posts will make it to the home. (This means more flexibility for non-mainstream posts)

Siebrand: @terry: A strategy the Language Engineering team uses is publish very technical posts on personal blogs, and then link there in more high level posts on the Wikimedia blog.

Guillaume on community curated tech news: E.g. Signpost technology report used to be more comprehensive (most bugs...), now more high-level. Fill this gap?

Erik: We have ourselves been getting better with e.g. release notes at Special:Version

Sumana: The mood in the community seems to be better now than a year ago?

(yes)

Ryan: one change is probably that before code contributions would not go through. That has improved with Gerrit.

Sumana: Code of Conduct: need to follow-up with LCA on urgency & how.

Sumana: we need to find better solutions for automated metrics.

Ryan: OpenStack is working on a cool solutions and it would be good to align with them.

Sumana wants money to have more OPW interns; metrics and analytics;

March 2012: 1 non-WMF core maintainer. Now: 11.

The comparison doesn't make much sense, it would be like saying "February 2012: 0", of course because gerrit didn't exist yet. A better comparison would be how many volunteer "maintainers" we had with SVN, helping with the review backlog etc. Some of the 11 are indeed new. --Nemo 21:16, 28 July 2013 (UTC)