<div dir="ltr"><div><div>I think you're right that the goal will be to spend as little as possible on "core" work. But if someone asks why we're spending so little on core, I don't see a problem explaining that we are spending more time on "strategic" work instead. I had no input into the selection of the word "core", but at least so far, I don't object to it. <br><br></div>Personally, I have no reason to expect there to be any kind of "50%" quotas, at the org or team level. Each team has a different context, and some might be doing 5% core work, and others might be doing 95% core work, and both might be doing exactly what they should to support the mission and vision. I can imagine a team seeing that it is spending a lot of time putting out fires, and end up choosing a quarterly goal to reduce their "core" effort on a certain system by half, or something like that. But it would be a means to an end (of being more efficient), not chosen just to make a number look pretty. <br><br></div><div>You mentioned a large gray area between core and strategic, and a desire not to be forced to put work into one bucket or the other. I agree that there will be ambiguities, but in those cases I don't have a problem picking one of the two buckets. That is different from the large gray area of work that is neither core nor strategic. If I were an executive or donor, I would look very warily at "other" work, and wonder why we're putting effort into it, if it is neither core nor strategic. For that work, I think it would be dysfunctional to try to jam it into one of the two buckets that it doesn't really belong in. <br><br></div><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Jan 6, 2016 at 11:21 AM, C. Scott Ananian <span dir="ltr"><<a href="mailto:cananian@wikimedia.org" target="_blank">cananian@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Kevin: your response is helpful, but it does confirm my impression that there currently is a large grey area between 'core' and 'strategic'. Trying to define a 'third term' for this grey area might be better than leaving it ambiguous, since otherwise there will be a great temptation to force things into one bucket or the other depending on "which is better for me at the moment". For example, if we say "ideally our work will be 50% core and 50% strategic", I'm pretty sure that I can just massage things to match that artificial target by slushing stuff over into one bucket or the other. Vague definitions corrupt the metrics and turn assessments into box-checking exercises. It seems the solution isn't tweaking the definition (which is what you're asking us to do) because the basic concepts presuppose a sharp distinction between "feature development" and "bug fixing" which doesn't align with actual development processes.<div><br></div><div>WRT to your first question: the common English word "core" has a connotation of importance and large size. Yes, perhaps the "core" work of the Foundation is actually keeping the servers running. But it certainly isn't the "core" of the work I do every day -- we try very hard to create services that *don't* require large ongoing maintenance burdens. If the "core" of my responsibilities was "core" work ("just keeping the lights on and the servers from falling over!"), I would conclude that we were flailing and that our software was not very well constructed.</div><div><br></div><div>Even among (say) the infrastructure group I suspect they would classify most of their work as "strategic" -- ongoing improvements to ensure that we can spend less and less time on the "core" of our mission. My point is just that there is cognitive dissonance between the common English usage and the use of this word in this planning context. We will inevitably asked why we try to spend only <small percentage> of our time on "core" tasks, if they are indeed "core" to our mission.</div><div><br></div><div>Perhaps these concepts make more sense for the legal department than they do for engineering.</div><div> --scott</div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Jan 6, 2016 at 9:54 AM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>I'm having a little trouble parsing your statement that "our 'core work' is maintenance now". When you say "our", do you mean your team, or the WMF as a whole? And when you say "now", do you mean "prior to this moment" or "after these new definitions go into effect"?<br><br></div><div>What follows are opinions off the top of my head. I could easily change my mind. <br></div><div><br></div>For me, it was helpful to consider Core/Strategic/Other as being completely independent of the concept of "maintenance". With that in mind, version 1 of a strategic feature would be strategic. Version 2 would probably also be strategic, since if a version 2 weren't necessary for strategic reasons, we probably shouldn't be working on it. Once the feature is "done" to the point of meeting the strategic needs, then keeping it running would probably be "Core" work. <br><br></div>Maintaining an existing feature would usually fall into the "core" bucket, although the way some people define "maintenance" it could actually be strategic. Or, if the feature really isn't serving the movement, that maintenance might be neither core nor strategic. There are a lot of gray areas, and in some cases there are no objectively "right" answers. We're hoping to build up the definitions and examples to the point where we can generally agree on which bucket a particular piece of work would go in. But there will always be some ambiguity at the edges. <br></div><br></div>All of that is really a better discussion for the wiki page, so I encourage you to take it up there. But I hope this helps. <br><br></div><div class="gmail_extra"><span><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br></span><div><div><div class="gmail_quote">On Tue, Jan 5, 2016 at 10:32 PM, C. Scott Ananian <span dir="ltr"><<a href="mailto:cananian@wikimedia.org" target="_blank">cananian@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">It definitely seems odd to me that our "core work" is maintenance now.</p>
<p dir="ltr">It also seems at odds with software development processes where the conventional wisdom is that "version 3" of the Thing is the version that is first generally useful and usable.</p>
<p dir="ltr">So building "version 1" is "strategic" and versions 3 and following are "core" (the Thing is presumably feature-complete then) but the long slog of bug fixing, refactoring, dealing with the inevitable encounters of design vs real world and rebuilding the parts which never worked... Is that maintenance ("core") or (we-didn't-realize-we-actually-needed-that-) feature development ("strategic")?</p>
<p dir="ltr">Much of the development on Parsoid and VE over the past two years has been of this sort. I don't think the proposed terminology is particularly helpful. I suppose I'd label all that feature-fixing as "strategic" just because it makes me feel better about my work.<span><font color="#888888"><br>
--scott</font></span></p><div><div>
<div class="gmail_quote">On Jan 5, 2016 12:36 PM, "Oliver Keyes" <<a href="mailto:okeyes@wikimedia.org" target="_blank">okeyes@wikimedia.org</a>> wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>So we created categories with values we don't know the meaning of?<br><br></div>That seems sort of backwards ;p.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div>On 5 January 2016 at 15:23, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr">Summary: <br>Please visit this wiki page[2] to help define the term "core work". <br><br><div>Long form:<br>The WMF annual planning process[1] is being revised this year in
several ways. One is to attempt to categorize work as
"Core", "Strategic", or "Other", which should help us
communicate our work externally, and to improve our internal budget and
strategic planning processes.<br><br>As Lila mentioned in a recent update, we need to define these terms. The Team Practices Group was
asked to help the stakeholders reach agreement on these definitions, so we have created a wiki
page[2] about "core". It contains a draft (strawdog) definition, along with rationale
and examples. Through the discussion there, the definition will be
refined so it can be used throughout the foundation. Note that this will not be limited to product development teams--it will be org-wide. <br><br><div>Early
planning for FY 2015-2016 will start next
week, and that will benefit from having a working definition. So if you have any strong feelings about this, please voice them as soon as
possible. However, I envision this as being a living definition which
can continue to evolve over time. So even if you can't participate this
week, please visit the page when you can, and share your ideas then. <br></div><div><br></div><div>This work relates to
various discussions and pilots last year related to "maintenance
fraction", and "interrupt" or "unplanned" work. However, this
conversation has a tighter focus, along with (hopefully) a clear
rationale for the categorization. It also relates to the "New/Reactive/Maintenance" categorization that have been used recently in the Quarterly Reviews, but is distinct from that as well. <br><br></div><div>Aside from annual planning, we believe that categorizing this work will help teams themselves. For example, it might help them realize when they are getting pulled into doing work that is neither core nor strategic, or it might help identify opportunities to invest in improvements that would greatly reduce the ongoing effort required to keep existing features working smoothly. <br></div><div><br></div><div>Please continue this
discussion on wiki, or email me (or just the Team Practices list) if you have process questions or concerns. <br></div><br>[1] <a href="https://wikimediafoundation.org/wiki/2015-2016_Annual_Plan/Questions_and_Answers" target="_blank">https://wikimediafoundation.org/wiki/2015-2016_Annual_Plan/Questions_and_Answers</a> <br>[2] <a href="https://www.mediawiki.org/wiki/Team_Practices_Group/Tracking_core_and_strategic_work" target="_blank">https://www.mediawiki.org/wiki/Team_Practices_Group/Tracking_core_and_strategic_work</a><div><div><img src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div><span><font color="#888888"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
</font></span></div></div>
<br></div>_______________________________________________<br>
Wmfall mailing list<br>
<a href="mailto:Wmfall@lists.wikimedia.org" target="_blank">Wmfall@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/wmfall" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/wmfall</a><br>
<br></blockquote></div><font color="#888888"><br><br clear="all"><br>-- <br><div>Oliver Keyes<br>Count Logula<br>Wikimedia Foundation</div>
</font></div>
<br>_______________________________________________<br>
Wmfall mailing list<br>
<a href="mailto:Wmfall@lists.wikimedia.org" target="_blank">Wmfall@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/wmfall" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/wmfall</a><br>
<br></blockquote></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div style="text-align:center">(<a href="http://cscott.net" target="_blank">http://cscott.net</a>)</div></div>
</font></span></div>
</blockquote></div><br></div>