Jump to content

Engineering Community Team/March 2014 Quarterly Review

From mediawiki.org

Review of the activity and plans of the Engineering Community team. For more details see our share of the Wikimedia Engineering goals, and our short term plans.

Summary

[edit]

To be posted after the review on 2014-03-27.

Last Completed Quarter, October - December, 2013

[edit]

Achievements

[edit]
  • All this with one person less and a reorganization of the team’s way of working.

Lessons learned

[edit]
  • Pairing works in a team of specialized individuals working remotely.
    • Better quality, less hesitation, steady motivation.
    • Good for special tasks, less for business-as-usual.
  • Monthly ECT Showcases contribute to short term planning and team collaboration.
  • Hiring for short contracts demanding community engagement doesn’t work.

Current Quarter, January - March, 2014

[edit]

Highlights

[edit]

Team overloaded

[edit]
  • Only Technical communications is on target.
  • Technical collaboration tools, Documentation, and Outreach programs have good progress, are in the good track, but carry delays and/org have to sacrifice quality and analysis due to the amount and diversity of pending work.
  • The goal of Upstream collaboration could be barely started, crowdsourced to the community (who luckily answered fast).

Areas welcoming recruitment

[edit]
  • Technical collaboration tools
    • IF we select Phabricator THEN Andre needs help migrating from Bugzilla, Gerrit, etc, and tuning the new infrastructure it to our needs.
    • We still need him as Bugmeister first.
  • Outreach programs
    • Quim is in execution mode; the result is less quality in his tasks, no capacity for analysis or mid term vision.
    • We need someone focusing in events, helping in programs.

Planning, April - June 2014

[edit]

Big new shiny goals

[edit]
  • Project Management tools plan ready for execution.
  • Architecture documentation DONE (Documentation is never done, but we can leave it in a decent state, not requiring full attention.)
  • Complete list of upstream projects with contacts.

… in addition to our goals on Google Summer of Code, FOSS Outreach Program for Women, Facebook Open Academy, and community metrics.

Bonus points

[edit]
  • Data Hub (provisional name) master plan agreed, prototype available.
  • Plan for annual hackathons in India and the USA.

Questions

[edit]
  • About the Data Hub, how far do we want to go promoting our API in 2014-15?
    • We need to match your expectations with our aspirations, and with resources available.
  • We keep wondering how the new Community Engagement team will affect us.

Meeting minutes

[edit]
Extracted from etherpad
Present: Quim, Jared, Howie, Terry, Toby, Erik M, RobLa
Remote: Andre, Sumana, Guillaume

2014-03-27

(Notes prepopulated with the content of 
https://www.mediawiki.org/wiki/Engineering_Community_Team/March_2014_Quarterly_Review -- edit at will.)


== Last Completed Quarter, October - December, 2013 ==

=== Achievements ===

* Successful debut in [[Google Code-in]]: 273 tasks resolved by 46 students supported by ~30 mentors. (trivia: Wikimedia and [http://www.apertium.org/ Apertium] topped the ranking of GCI projects by tasks completed, both with 273)
* Week by week, [[m:Tech/News|Tech News]] becomes the undisputed reference for Wikimedia technical information.
* Ongoing: [[Project management tools/Review|Project Management tools]], [[bugzilla:49597|Bugzilla upgrade]], [[Architecture Summit 2014/RFC clusters|Architecture Summit]], [[FOSS Outreach Program for Women/Round 7|OPW]], [[mailarchive:wikitech-l/2013-November/073077.html|tech writer hiring]]…

* All this with one person less and a reorganization of the team’s way of working.

=== Lessons learned ===

* Pairing works in a team of specialized individuals working remotely.
** Better quality, less hesitation, steady motivation.
** Good for special tasks, less for business-as-usual.
* Monthly ECT Showcases contribute to short-term planning and team collaboration.

Erik: Thinking about how we showcase not just our work, but the work of our best volunteer developers. Is there a way to make this a part of it? For instance a PM might not be aware of what a Community member did a while ago.

'''ACTION ITEM: follow up on Erik's idea ^^^'''

Quim: This is a good idea, needs more thought on how to implement

Toby: Are you find that there is additional overhead in people working together, remotely>

Quim: We don't have the luxury to have much overhead. 

Guillaume: One advantage is we're in the same timezone (Andre), and we coordinate over IRC and e-mail based on convenience, if we identify what we need to do and who needs to do it, then we can work independently and sync when needed. Doesn't seem to be much overhead / much concern

Quim: When coordinated with Andre, it's less about trying to meet every day, and more about coordinating when there is something unusual.

* Hiring for short contracts demanding community engagement doesn’t work.

Quim: Spent much time trying to hire Tech Writer and didn't succeed. Reason: combined too many requirements (community expertise). Contracts should probably reserved for specific things (short and quick) and use permanent for things.

RobLa: Eventually found Sumana for the role.

== Current Quarter, January - March, 2014==

=== Highlights ===

* [[Project management tools/Review|Project Management tools review]] slower than planned, but smoother than expected.

Erik:  previously the big question was technical resources. Team has  evaluation piece, but what is the current thinking on resourcing? Is the  scope as an open alternative to Mingle, Trello, etc? Also alternative  to Gerrit?

RobLa:  If it is just in the scope of project management tool, we can deploy  Phabricator as a first phase. But migrating bugzilla over but that is a  big project. If we are going to block on that… There is a debate on the  mailing list, and asserting that we shouldn't' do anything to migrate  bugzilla over. May be declaring an intent to migrate over to Phabricator  (for all of that: bugzilla, gerrit).

Erik:  Right now it sounds the only resourcing in Platform, then we can set up  something more stable than wmflabs, but beyond that?

RobLa:  still trying to figure out what to do in the coming quarter. Might be  the mediawiki core team, but the risk is losing that velocity among the  core developers. Chad is eager to get started but has other  responsibilities, but needs a couple more people than that. Requested  money in budgeting for Phabricator, etc.

Erik: What is the framing in the RfC for work on Phabricator?

Guillaume:  Identify the blockers, where we are now, and what is the outcome. The  other goal is to choose explicitly between status quo and phabricator,  or use the currrent tools and just use phabricator for the PM tools.

Erik:  We don't know yet, we're tryign to find out, there might be blockers to  move this to another year, but if we decide to move forward, we should  consider resourcing (ops, platform, etc.)

Jared:  From the ATS testing, there is a difference between testing it and  using it. Consider a smaller team to use it (e.g. Multimedia?)

RobLa:  Multimedia might be good because they're using Mingle but have an  engineer who is a big fan of Phabricator. But they're reasonably happy  with Mingle.

Toby:  For analytics team, Mingle is not working and we're looking for what to  do? The best way to get the team to something as radical as this to  solve the biggest problem which is the Mingle/Trello piece. But need  something that works, than something open,

RobLa:  Downside of this is Phabricator is a code review system best, decent  bug/defect tracking, but only started as a project management tool. On  the plus side, the velocity of the project is really high. Needs a team  that is more forgiving.

Quim: join office hours and RfC

Toby: Not broken for teams. Bugzilla is working and Gerrit is working, but the need is project management tool.

Erik: This is an integrating solution. This is mingle plus bugzilla, etc.

Toby: Altenrative is that others have got PM tools written on top of bugzilla with integration into SCM system.

Jared:  People are excited about replacing parts of the tools that are actively  hostile. The project management tool is definitely a step back.

Erik: It's totally not there, but Bugzilla has even more primative model.

* Transition of [[mailarchive:wikitech-l/2014-March/075308.html|Sumana to a new tech writer role]], consolidates the [[Requests for comment|Architecture RfC process]]., and working on some architecture guidelines

Sumana: focusing on RfC process and solidfy guidelines (3 main documents + other stuff: training, cheat sheets), 1) architecture guidelines; 2) performance guidelines; 3) security guidelines. Will work with Ryan, Ori and Chris in January and sprint in Architecture summit in Zurich and finish targeted for end fo fiscal year. Works better when asking directly what people want to expect from their RfC. Would like to see more 3rd party uptake (e.g. Wikia).

Jared: consider it to be less technical in nomenclature.

Sumana: When work directly with people (e.g. Mark Bergsma on Ops, Ori on minifying) the discussions happen, but not sustainable place

Erik: There has been a lot more participation on the RfC since the summit which is great. What I don't know is that we wanted to get into the weekly habit, is that happening?

Sumana: 2PM on Wednesdays (the architects are there).

Erik: Have we gotten the non-usual suspects to participate?

Sumana: I'm not happy with that level of stuff. Some of the folks in mobile and a few platform people, and C Scott (scope language converter), but I haven't had enough uptake of Features group. There is front-end archtiecture discussion stuff that is happening (sometiems Roan, Trevor and Krinkle comment) but their work in RfC form is perhaps missing.

Erik: Was there someone from Flow yet?

Sumana: IN the HTL templating stuff, they're testing the knockout templating proposal, but not part of review.

Erik: Consider prod them to participate.

'''ACTION ITEM: prod Erik B and Flow engineers to participate in some of the RfC weekly meetings'''

* [[mailarchive:wikitech-l/2014-March/075146.html|OPW Round 7 sets a new benchmark]] for success in outreach programs: code merged, work deployed.

Quim: 6 projects completed (code merged in parsoid, published in code academy, proposal for new homepage on mw.org, functional feature showing for upload wizard with OSM). Need to nail down continuity of interns beyond OPW. Sumana has started some work here, but we need to nail it down.

Sumana: Interns who have expeirnece with us contribute to OS generally. This was GSoC but now OPW. We might need to look 1-2 years out for this. (e.g. 2013 OPW intern working with Analytics right now).

Toby: She really persevered (was a little too junior for hire), but she kept participating and when we had contracting needs, we turned to her.

Sumana: People relationship to continue volunteering until their skill/expeirence level reaches the point that enables further opportunities. Informal mentorship continuing could be key!

Quim: We participate in so many programs that every quarter this is a point of discussion.

* New [http://korma.wmflabs.org tech community metrics] help us discover trends plus the best and the most neglected areas. (announcement coming soon)

Quim: Need to finish the quarter before analysis/discussion. For the project itself it's more on maintenance and the attention goes onto triggerring actions.

Erik: May want to call out some of these stories discovered on Monthly Metrics

=== Team overloaded ===

* Only Technical communications is on target.
* Technical collaboration tools, Documentation, and Outreach programs have good progress, are in the good track, but carry delays and/org have to sacrifice quality and analysis due to the amount and diversity of pending work.
* The goal of [[Upstream projects|Upstream collaboration]] could be barely started, crowdsourced to the community (who luckily answered fast).


=== Areas welcoming recruitment ===
* Technical collaboration tools
** IF we select Phabricator THEN Andre needs help migrating from Bugzilla, Gerrit, etc, and tuning the new infrastructure it to our needs.
** We still need him as Bugmeister first.

If Phabricator then it's for everything, not just a piece, but no experience to do everything.

Erik: Is Dan a part of the piece?

RobLa: He is not a part of the process. Considering him a possibility.  That would be Howie's call.

Erik: Maybe involve him for scoping and prioritization piece?

Howie: We're still in the selection piece. So need to get past that first.

* Outreach programs
** Quim is in execution mode; the result is less quality in his tasks, no capacity for analysis or mid term vision.
** We need someone focusing in events, helping in programs.

Can't do meetups, tech talks because of limited capacity.

== Planning, April - June 2014 ==

=== Big new shiny goals ===

* Project Management tools plan ready for execution.
* Architecture documentation DONE <sub>(Documentation is never done, but we can leave it in a decent state, not requiring full attention.)</sub>
* Complete list of [[upstream projects]] with contacts.
… in addition to our goals on [[Google Summer of Code 2014|Google Summer of Code]], [[FOSS Outreach Program for Women/Round 8|FOSS Outreach Program for Women]], [[Facebook Open Academy]], and [[community metrics]].

RobLa: Upstream collaboration piece. We develop a lot of tools but build our own thing, but don't invest to the point where others might use it and it'll become a mediawiki specific legacy thing.

=== Bonus points ===

* ''[[Data & Developer Hub|Data Hub]]'' (provisional name) master plan agreed, prototype available.
* Plan for annual hackathons in India and the USA.

** idea: facilitate local community members organizing the events

== Questions ==

* About the ''[[Data & Developer Hub|Data Hub]]'', how far do we want to go promoting our API in 2014-15?
** We need to match your expectations with our aspirations, and with resources available.

Make sure this is about real users & real developers on a continuing basis. Concrete example: API self-documents with api.php, but that's easily and we could clean it up, integrate it with the Sandbox. We could even get analytics on how many people hit that page. (We also need to vet it for accuracy!)
* maybe put another step in that crosslinks things in api.php.... 
* SOA (service-oriented architecture) drive. Separating components of MediaWiki into different services - give internal MW developers the docs they need.
** Internal priorities but packaged in a manner polished enough for external delivery

In addition to the APIs that new hires need, Rashomon might be first from a visibility standpoint? May be a few months out till we have anything end-user-facing.
* in future, Sumana to check with Gabriel as go-to person for Rashomon, citation or redlinks API, establishing more standards

* consider Wikidata's new query service, converse with WMDE, think about whether/how to prioritise Wikidata APIs in datahub/docs project

* We keep wondering how the new Community Engagement team will affect us.
Retrieved from "https://www.mediawiki.org/w/index.php?title=Engineering_Community_Team/March_2014_Quarterly_Review&oldid=5925998"