For the record, that's basically the heuristic (combo of James and Arthur's) that I've been using when people ask me for special deploy windows.
So, +1 from me. Greg <quote name="Arthur Richards" date="2013-10-17" time="10:41:06 -0700"> > +teampractices and wikitech-l for more input > > > On Wed, Oct 16, 2013 at 11:22 AM, Arthur Richards > <[email protected]>wrote: > > > I generally agree with James'/VE's approach. I'm not sure we can > > reasonably come up with a sound metric (eg 'degredation that affects > > roughly one percent of users') as it may not always be easily measurable. I > > think a gut-check, qualitative assessment should suffice for these kinds of > > issues, and can probably be broken into a few buckets: > > > > *) critical functionality is BROKEN (eg edits are not being saved, article > > content is not accessible), there is a security concern, or a legal issue - > > this needs to be fixed ASAP, like possibly before the next lightning deploy > > *) semi-critical functionality is broken but doesn't impede basic usage of > > critical site components (imo: reading, editing [in that order]) - (eg the > > watchlist star on an article doesn't accurately indicate if an article is > > being watched) - fixed and backported with earliest possible lightning > > deploy window > > *) annoyances (styling not quite right, obscure javascript errors), > > non-security/legal issues in beta/alpha versions - fixed with next > > deployment train > > > > This has generally been our approach to date on the mobile web team, > > although I don't think we've ever been explicit about a rubric. > > > > > > On Tue, Oct 15, 2013 at 1:53 PM, James Forrester <[email protected] > > > wrote: > > > >> Kenan, > >> > >> For VE we backport (cherry pick) fixes of major issues ASAP (generally by > >> grabbing the next available Lightning Deploy window after we've tested it), > >> but for inconveniences (i.e., things not quite as intended but still > >> workable, or only affecting a few users) we generally just go for the next > >> week's deployment train instead. Otherwise, yeah, they just join the > >> backlog. > >> > >> J. > >> > >> > >> On 15 October 2013 13:49, Kenan Wang <[email protected]> wrote: > >> > >>> Hey, > >>> > >>> The mobile team just got onto the deployment train. We're currently > >>> looking to understand what we do when we find bugs caused by the previous > >>> release during the deployment train. I proposed a three tiered triage > >>> system to my team: > >>> > >>> Current train: degradation that affects roughly one percent of users in > >>> a noticeable way > >>> Current iteration, next train: degradation that affects less than one > >>> percent of users in a noticeable way > >>> Backlog: degradation that affects less than .1 percent of users in a > >>> noticeable way, or affects users in a cursory way > >>> > >>> But was wondering if there were any other systems that teams had in > >>> place to deal with this issue. > >>> > >>> Also, if you fix a bug does your team typically deploy during the next > >>> deployment window available or do you wait to deploy until you have a > >>> couple of fixes? > >>> > >>> -- > >>> > >>> Kenan Wang > >>> Product Manager, Mobile > >>> Wikimedia Foundation > >>> > >>> _______________________________________________ > >>> Wmfproduct mailing list > >>> [email protected] > >>> https://lists.wikimedia.org/mailman/listinfo/wmfproduct > >>> > >>> > >> > >> > >> -- > >> James D. Forrester > >> Product Manager, VisualEditor > >> Wikimedia Foundation, Inc. > >> > >> [email protected] | @jdforrester > >> > > > > > > > > -- > > Arthur Richards > > Software Engineer, Mobile > > [[User:Awjrichards]] > > IRC: awjr > > +1-415-839-6885 x6687 > > > > > > -- > Arthur Richards > Software Engineer, Mobile > [[User:Awjrichards]] > IRC: awjr > +1-415-839-6885 x6687 > _______________________________________________ > teampractices mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/teampractices -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
