Engineering Community Team/June 2014 Quarterly Review

Meeting minutes
Present: Andre, Guillame, Rachel F, Rachel d, Summana, Tomasz, Erik M, Robla, Quim, Terry Chay

Opening: Quim:

Slides: https://docs.google.com/a/wikimedia.org/presentation/d/1biZ0lclFU7vbyoX1GQU34i-OhsfhTf_-O4A6SdXVvdU/edit#slide=id.g34c867c71_026

- What matters is the line - Return to Metrics (Alpha) - EM (Questions about changes, Do we have a stable set of contributor/User names - QG Yes, we are trying to calculate, but we are not sure how reliable data is. Intention will be to see if there is some difference between staff and nonstaff - EM May need to specify types, volunteer vs internal may be different Age of unreviewed patches -QG possible we are faster with what is recent but not making judgements good or bad, technical debt, recomendation: pay attention and not levav things out there -RobLa next steps: get a conversation going about this and see what the narrative is behind some of this Mediawiki core = 32 days median QG - if this is happening in 32 days in mediawiki core, other projects don't have an excuse EM - (review of different projects and age of unreviewed patches) - What do some projects do right, etc QG - We are still not able to distiquish which come from inside and the outside (ex PyWikiBot) - Just showing numbers can help highlight the issue ACTION: Quim to figure out process to remove WIP patches ACTION: Quim to send out note to wikitech-l about code review metrics Unresoved Bugzilla Reports (Unresolved by month) Unresolved means unreovled (373) is the median, rank of longest unresolved bugs to get queues moving Improving but we need to make more progress EM - when will you begin to report high level numbers at metrics? QG - we don't want to until the numbers are solid Robla - get it out on wikitech-l - if we look at it uncritically
 * Metrics
 * Code Contributors
 * Active Bugzilla Users
 * Mediawiki.org Editors
 * Mailing List Posters - How many are we? ~500, (Erik M - Which lists are included?)
 * Code review queue (772 changes)

Questions (Metrics)? 0

Midterm Plan - 3 big topics 1) A Sane Developer Experience Su - Difficult to get folks up to speed - especially meidawiki.org (Questions from slide) Robla - SDE -API Portal, cleaning up documentation, Tools (andre will elaborate) QG - Data, A SDE & Do whatever it takes. Focus - 3rd party software using our data w/o our help. SDE = Portal, cleanup, homepage project EM- Hard to reason about goals at this level - ideas - Success = not just a usable document, but ongoing living usable document, healthy workflows for documentation should be integrated with developer workflows, make that as a high level goal (experience and process by which the experience can be maintained) QM - Bring MW.org to the task, tempting to find solutions elsewhere, but it is the main place. We need discussion and buy in. MW.org need the focus of our efforts EM - Have we done a full inventory of all sorces of technical documentation that exists? Su - the data/developer hubpage has an inventory - (not exhaustive -but pretty exhaustive) EM - would like to do more brainstorming around the information architecture for this project Su - ? Are Gabriels plans public? EM - Yes QG - Developer Expereince - "I am a devloper. What can I do?"

One development platform Andre - (slide), we have to create a lot of infrastructure, now - discussions are scattered and hard to follow, 6th month discussion about how to make things easier. RFC for moving to Phabricator - scrumbugz, gerrit, jenkins as tools are not where the are yet where we want them ot be. Phabricator is written in PhP (so it is easier for more people to use). QG - useful for software projects but also for non software projects, 1st Phab project - for LCA team EM - expectation for move to Phabricator will be big, scary, anxiety inducing, very possible that Phab will be useful as an organizational tool, but w/history and datea in BZ, the migration will be difficult QG - acknowledge it is "scary" but necessary to mention EM - ? When things get serious with Phab, will we have a check-in? Andre - intentionally no time frame at this time (4-12 months possibly) - Currently, no firm expectation Robla - Keep in mind - MWcore would like to use a solution and would like it soon. It would be a difficult sell to use Trello or another, would prefer Phabricator but teams should be able to opt in much sooner if needed QG - Phab between July 1 and ? (prefer to fail than set up an expection of 12 mths) Robla - underpromising can also be an issue - (Discussion regarding migration and timing) ACTION: Erik to speak with TechOps about Phabricator timing

Engage Established Communities QG - (read slide) Focus on Collectives - as a way to scale, bringing a different return EM - Outreach flag - significantly strengthen working relationship between ECT and recruiting, hiring for diveristy and other groups, only a loose connection at the moment, senior recruiting manager coming onboard who can be key to this Su - Would love to institute off-boarding at the end of intership, person gets to talk with WMF recruiter. EM - Hiring process at moment is not fit for the organization we have become - the process will be examined to fit different types of positions and reduce friction in communications and handover processes. As we solve problem, recruiting will partner w/hiring managers - opportunity between ECT & Recruiting QG - planning on getting more students and interns ACTION: work with new recruiting manager on more explicitly recruiting from internship programs

Groups:  1) Open Source Upstreams - not just projects but communities around them (ex. PHP community) 2) Diverse devoloper groups - girls who code, js developers in latin america - commuities of diversity (EX - meetups) 3) Explore WM partnerships through Education, W0, chapters - in touch w/university, operators in different territories, - Suggestion - document and formalize

Questions? 0

July/September 2014

Big Shiny Goals

QG - Read slide

Questions for Andre & Su

Su: Yay :)

Highlights

QG - Read slide (Comments - Amazing community) SU - Documentaton - Sig process made on architecture, security and performance guidelines, PD - still a living document, Chris/Brian working on A & S guidlines and progressing toward tutorials/posters, more to come QG - Su will need to go to API project, moving forward with documentation - July 15, 2014 = Done Robla - How is RfC process working? SU - A lot better off but room for improvement; will hand off some scheduling to RF. More RfCs are coming in - not being closed at the same rate. Expect increasing RfCs. Some moves forward (HTML templating, structured logging, thumbnails) Robla - Process seems to be improving SU - More frequent meetings/more systematic inclusion of folks from design and Robla - We have momentum but there is more we can do to keep things on pace - engineeringwide discussion SU - PM of RfC and PM who's job it is to get folks to take action on RfCs Discussion - Ownership of RfCs/ improvement of flow & communication/ messaging to department and community

QG - Tech Talks & SF Tech Meetup (Props to RF) RF - Excited/ready to take on more events QG - Up to speed RE events for this quarter GP - one year of tech news - 30-40 community subscribers, others via Atom feeds, employees, volunteers contibute, # of edits/# contributions QG - Highlights/problems/teams all relate to each other. Connecting needs w/actions is the big part of the work. TN and TT are critical for communication and connections, making (the right) conversations happen

Team Overload

QG - Slide from March 2014 (Team overload) / June 2014 (Team less overloaded) - Documentation is strong. Events are strong. Progress forward. Plan for coming overload (read slide) Robla - Mukunda will have an ongoing role w/Phabricator

Overcoming Overload QG - Review slide - colab with other WMF teams. Finding ways for other teams to "work for us" - Community engagement & empowerment. GSoC (and other programs) empowers mentors.

Questions: EM: Priorities? QG - imp - useful when it is clear that ECT will make the decision. Sometimes there is resistence. It is helpful for ECT to have the final decision making power (and responsiblity). Continued support from EM appreciated.