<div dir="ltr">To me, the basic problem is that all these classifications are based on relatively subjective judgments of what is good (vs. debt), necessary or optional. Reasonable people can and do disagree on this.<div><br></div><div>To establish meaningful numbers, we would need to classify work with a reasonably uniform set of priorities in mind. Since these numbers were requested by Lila, it might make sense to try to classify work based on what we know of Lila's priorities.</div><div><br></div><div>Gabriel </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 11, 2015 at 9:57 AM, David Strine <span dir="ltr"><<a href="mailto:dstrine@wikimedia.org" target="_blank">dstrine@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">Just to throw my 2 cents in here. <div><br></div><div>I am a huge fan for data analysis and categorization of work. It empowers us to make more informed decisions. </div><div><br></div><div>I'm objectively opposed to apriori buffering or assumed capacity for certain amounts of work. There have been some comments on the thread about how much maintenance people "should" be doing or guessing percentages.</div><div><br></div><div>I prefer tagging work within categories, watching trends over time and then making decisions and budgeting based on some historic indications. FR-etch started tracking "unplanned" work about 6 weeks ago and we're just now getting enough data to try and describe those tasks. We're discussing adding more tags for finer grained tracking. <div><br></div><div>The goal to track categories of work is technically possible with phabricator but may require a lot of hand generated reports and regular, manual maintenance.  </div><div><br></div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Aug 11, 2015 at 9:40 AM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Aug 10, 2015 at 10:20 AM, Bryan Davis <span dir="ltr"><<a href="mailto:bd808@wikimedia.org" target="_blank">bd808@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think I would personally invert Kevin's assertion and say that most<br>
teams are (or should be) spending a non-trivial amount of time<br>
performing both maintenance and responsive correction work. Hopefully<br>
this doesn't rise above a reasonable threshold (say 30%) of the full<br>
team capacity, but it really would always be there. </blockquote><div><br></div></span><div>I actually proposed 10-20% as a guess, and you're saying not more than 30%. So I don't see much disagreement between us about the amount of time a team should spend on maintenance. <br><br></div><div> I'm not sure yet on the "keeping the lights on" vs. "maintenance" distinction, but I don't think that matters right now. <br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This "burden" is not unique to the WMF or FLOSS systems. This is one<br>
of the reasons that a typical software development organization with<br>
stable funding grows its developer team at a fairly constant rate.<br>
That head count growth doesn't go into acceleration of new<br>
development; it is instead used to offset the constantly increasing<br>
maintenance cost of running a successful software product. </blockquote><div><br></div></span><div>I'm not sure exactly what you mean, but there's a chance I might disagree. If you are suggesting an inevitability that code will become harder and harder to maintain over time, I'll push back. Yes, most teams end up needing more developers to compensate for ever-increasing tech debt, but that effect can be reduced, if not avoided. I worked on a 14-year-old codebase, and although it was far from perfect, it remained quite maintainable. That was mostly thanks to extensive unit tests, strict coding styles, and ongoing aggressive refactoring. <br><span><font color="#888888"><br></font></span></div><span><font color="#888888">Kevin<br></font></span></div></div></div>
<br></div></div><span class="">_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Gabriel Wicke<div>Principal Engineer, Wikimedia Foundation</div></div></div>
</div>