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.

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;