I'm trying to compare the feeling of the group (that we know exactly why we are here and how this aligns with the WMF mission) and my personal feeling (that we do whatever is asked and often the asks are questionable).
I'm willing to admit that some of the difference in viewpoint is based on the particular work that I have done over the last year. I have been on loan to Multimedia, developed Wikimania Scholarships, on loan to Release Engineering and developed IEG grant review. In between and overlapping I worked briefly on the "DevOps sprint", setup logstash, rewrote scap and dabbled in HHVM related research. This level of bouncing around and number of solo projects has not given me a great feeling that I'm on a well scoped team. It actually makes me feel like I'm just a gun for hire (or worse monkey at a keyboard) to be called to service whenever and wherever RobLa and Erik feel an extra hand is needed.
I'm not looking for pity or a "you're doing good job Bryan" out of this rant, I'm just trying to make my point of view clear. I've actually generally enjoyed the work that I've done here and have certainly had plenty of things to keep me busy and learning. I am however interested in acquiring a better model of what it is that I should be trying to do when I have the opportunity to choose work from the never ending list of things that could be done. I feel that this is important not just for me personally but for the team as a group when doing things like grooming our collective project backlog and defending our choices to management.
I went to the wiki page for our group [0] and found this list of "responsibilities" for the MediaWiki Core team: * Manage the MediaWiki release cycle * Ensure that MediaWiki core is meeting the evolving needs of the website * Make quality MediaWiki releases available for others outside of the Wikimedia Foundation * Develop and document a clear set of APIs so that external developers can create applications that easily interface with MediaWiki
This seems out of date to me. I think that the newly formed Release Engineering team is responsible for the first and third bullet points. That leaves "meeting the evolving needs of the website" and "develop and document a clear set of APIs" still on our plate. Neither of these seems like something that can be used to exclude much work from consideration. This can be seen as a good thing when the team is presenting their ideas outwardly, but it seems like a double edged sword for incoming work requests. It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations.
I think it would be a worthwhile exercise to spend some time next week talking about what it is that we do here and what reasonable boundaries and expectations we would like to set with the Foundation and the community.
[0]: https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering#MediaWiki_Core
Bryan
On Oct 7, 2014 1:40 AM, "Bryan Davis" bd808@wikimedia.org wrote:
I'm trying to compare the feeling of the group (that we know exactly why we are here and how this aligns with the WMF mission) and my personal feeling (that we do whatever is asked and often the asks are questionable).
I'm willing to admit that some of the difference in viewpoint is based on the particular work that I have done over the last year. I have been on loan to Multimedia, developed Wikimania Scholarships, on loan to Release Engineering and developed IEG grant review. In between and overlapping I worked briefly on the "DevOps sprint", setup logstash, rewrote scap and dabbled in HHVM related research. This level of bouncing around and number of solo projects has not given me a great feeling that I'm on a well scoped team. It actually makes me feel like I'm just a gun for hire (or worse monkey at a keyboard) to be called to service whenever and wherever RobLa and Erik feel an extra hand is needed.
I'm not looking for pity or a "you're doing good job Bryan" out of this rant, I'm just trying to make my point of view clear. I've actually generally enjoyed the work that I've done here and have certainly had plenty of things to keep me busy and learning. I am however interested in acquiring a better model of what it is that I should be trying to do when I have the opportunity to choose work from the never ending list of things that could be done. I feel that this is important not just for me personally but for the team as a group when doing things like grooming our collective project backlog and defending our choices to management.
I went to the wiki page for our group [0] and found this list of "responsibilities" for the MediaWiki Core team:
- Manage the MediaWiki release cycle
- Ensure that MediaWiki core is meeting the evolving needs of the website
- Make quality MediaWiki releases available for others outside of the
Wikimedia Foundation
- Develop and document a clear set of APIs so that external developers
can create applications that easily interface with MediaWiki
This seems out of date to me. I think that the newly formed Release Engineering team is responsible for the first and third bullet points. That leaves "meeting the evolving needs of the website" and "develop and document a clear set of APIs" still on our plate. Neither of these seems like something that can be used to exclude much work from consideration. This can be seen as a good thing when the team is presenting their ideas outwardly, but it seems like a double edged sword for incoming work requests. It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations.
I think it would be a worthwhile exercise to spend some time next week talking about what it is that we do here and what reasonable boundaries and expectations we would like to set with the Foundation and the community.
Absolutely. I think all the dissenting opinions need some time next week but this one is the most worthy. I think the team agrees that our role is ill defined or I'll documented and probably both. The awesome vote came because, whatever our actual role is, we're damn sure it's crucial to the foundation. I think this is weird and absolutely worth talking about.
On Tue, Oct 7, 2014 at 1:02 AM, Bryan Davis bd808@wikimedia.org wrote:
I'm trying to compare the feeling of the group (that we know exactly why we are here and how this aligns with the WMF mission) and my personal feeling (that we do whatever is asked and often the asks are questionable).
The way I see it, our team mission is basically "we do the stuff other teams don't": very important and essential to the WMF mission, but very ill-defined and subject to getting miscellaneous stuff shoved on us where creating a dedicated team is overkill (or just not in the budget).
I'm used to that sort of work, since my previous jobs have been along the lines of "Brad does everything computer-related" or "Brad does everything complicated that's computer-related". It's nice here *not* being the only one doing stuff while still mostly working individually as I'm used to (although more team-work would probably be better for my professional development; I should also exercise more and spend less non-work time on the computer).
I went to the wiki page for our group [0] and found this list of
"responsibilities" for the MediaWiki Core team:
- Manage the MediaWiki release cycle
- Ensure that MediaWiki core is meeting the evolving needs of the website
- Make quality MediaWiki releases available for others outside of the
Wikimedia Foundation
- Develop and document a clear set of APIs so that external developers
can create applications that easily interface with MediaWiki
This seems out of date to me. I think that the newly formed Release Engineering team is responsible for the first and third bullet points.
I completely agree there. Although the cause is obvious: Release Engineering was basically split off from us, taking the two bullets with them.
It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations.
+1, although that may fall under the extremely broad "Ensure that MediaWiki core is meeting the evolving needs of the website".
On Tue, Oct 7, 2014 at 7:07 AM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Tue, Oct 7, 2014 at 1:02 AM, Bryan Davis bd808@wikimedia.org wrote:
It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations.
+1, although that may fall under the extremely broad "Ensure that MediaWiki core is meeting the evolving needs of the website".
That's the problem with "responsibilities" instead of a "mission". One changes/evolves much more quickly than the other. I see responsibilities as the "how" and the mission as the "why"-ish.
Why does Core Team do all of this (disconnected at times) work? Because (partially from what Chris quoted): "[S]tability, security, performance and architectural cleanliness of the system" is important and this is the (only) team that can lead the work.
On Tue, Oct 7, 2014 at 1:20 PM, Greg Grossmeier greg@wikimedia.org wrote:
On Tue, Oct 7, 2014 at 7:07 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
On Tue, Oct 7, 2014 at 1:02 AM, Bryan Davis bd808@wikimedia.org wrote:
It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations.
+1, although that may fall under the extremely broad "Ensure that MediaWiki core is meeting the evolving needs of the website".
That's the problem with "responsibilities" instead of a "mission". One changes/evolves much more quickly than the other. I see responsibilities as the "how" and the mission as the "why"-ish.
Why does Core Team do all of this (disconnected at times) work? Because (partially from what Chris quoted): "[S]tability, security, performance and architectural cleanliness of the system" is important and this is the (only) team that can lead the work.
That makes sense for a lot of what we work on. Except Bryan - a good chunk of what he's had to work on has just been because someone had to do it and he's smart. Its not critical for "the system" (presumably mediawiki and everything in its orbit in production). Its critical for the foundation though.
Nik
On Tue, Oct 7, 2014 at 10:28 AM, Nikolas Everett neverett@wikimedia.org wrote:
That makes sense for a lot of what we work on. Except Bryan - a good chunk of what he's had to work on has just been because someone had to do it and he's smart. Its not critical for "the system" (presumably mediawiki and everything in its orbit in production). Its critical for the foundation though.
Yeah, and hence Bryan starting this (completely understandable) thread instead of eg you. :)
The "critical for the foundation" stuff that doesn't fit within any specific team tends to come to MW Core, and that's a problem that was identified by robla and others in the eng. management circle. Proposals on how to fix that more than welcome.
On Tuesday, October 7, 2014, Greg Grossmeier greg@wikimedia.org wrote:
The "critical for the foundation" stuff that doesn't fit within any specific team tends to come to MW Core, and that's a problem that was identified by robla and others in the eng. management circle. Proposals on how to fix that more than welcome.
Basically I think it comes down to agreeing as a team on the team's scope, making that scope known in a public venue, then holding people accountable to explaining how their proposed project for the team meets that scope.
I felt that yesterday there was a small amount of disagreement about the team's scope. Getting that ironed out should be the first step! If you fundamentally can't agree on that, that's okay, because you can split into smaller, more tightly scoped teams that work very closely together. You'In fact, if you do it right, other teams won't even know! For example, we've already done that splitting in Mobile Apps, as we have separate iOS and Android engineering sub teams, as part of the wider Mobile Apps team. This was done, in part, to combat the perception that engineers can easily hop between platforms, so that they have time to focus on a single platform and not get distracted. But you wouldn't know this from the outside!
Then it's about rejecting work that's outside the scope. In Mobile Apps that's a team-level decision, not a director-level one, but that's only possible because as a team we're all in total agreement on our team scope. So, first things first, get the scope agreement.
Just my opinion. Hopefully it was helpful.
Dan
On Tue, Oct 7, 2014 at 11:02 AM, Dan Garry dgarry@wikimedia.org wrote:
On Tuesday, October 7, 2014, Greg Grossmeier greg@wikimedia.org wrote:
The "critical for the foundation" stuff that doesn't fit within any specific team tends to come to MW Core, and that's a problem that was identified by robla and others in the eng. management circle. Proposals on how to fix that more than welcome.
Basically I think it comes down to agreeing as a team on the team's scope, making that scope known in a public venue, then holding people accountable to explaining how their proposed project for the team meets that scope.
MW Core has a scope, see the responsibilities that Chris quoted. It's just that the scope doesn't matter when a C-level comes along and says "Erik (now Damon), we need X by Y, please do it." That request rarely (if ever, I've never seen it) goes to any other team than MW Core. I've never see Editing or Flow or Mobile or Multimedia take on things like an IEG review system. Ever.
There aren't many good solutions to this problem, but there are many bad ones :)
On 7 October 2014 11:07, Greg Grossmeier greg@wikimedia.org wrote:
MW Core has a scope, see the responsibilities that Chris quoted. It's just that the scope doesn't matter when a C-level comes along and says "Erik (now Damon), we need X by Y, please do it." That request rarely (if ever, I've never seen it) goes to any other team than MW Core. I've never see Editing or Flow or Mobile or Multimedia take on things like an IEG review system. Ever.
I agree. Something's badly broken here.
However, that's not to say that the Mobile doesn't have stuff thrown on it that isn't its responsibility. The requests are not totally unrelated like the IEG thing, but they do come along. However, the Mobile Apps process allows us to reject this work as being outside of scope due to what I described above.
I still think that ironing out the internal scope disagreement is the first step. Then you can move from there. :-)
Dan
On Mon, Oct 6, 2014 at 10:02 PM, Bryan Davis bd808@wikimedia.org wrote:
This seems out of date to me. I think that the newly formed Release Engineering team is responsible for the first and third bullet points. That leaves "meeting the evolving needs of the website" and "develop and document a clear set of APIs" still on our plate. Neither of these seems like something that can be used to exclude much work from consideration. This can be seen as a good thing when the team is presenting their ideas outwardly, but it seems like a double edged sword for incoming work requests. It also feels like something is missing here. I really don't see any mention of our team's role in code review and stewardship of quality for MediaWiki and responsibility for security and performance considerations.
Also slightly out of date, but this is the document that I always think of when I think about what it is we do on Core. Possibly more descriptive than prescriptive:
"MediaWiki Core -- This group is responsible for stability, security, performance and architectural cleanliness of the system. This ends up translating into a lot of code review, along with infrastructure projects like disk-backed object cache, heterogeneous deployment, continuous integration, and over the course of the next year, a migration to HipHop. While not a prerequisite, everyone on this team started off as a volunteer developer. The whole engineering organization has some level of responsibility for our code review process, but this group has more of a primary responsibility for it than most groups." - https://blog.wikimedia.org/2011/08/17/what-is-platform-engineering/
mediawiki-core@lists.wikimedia.org