+teampractices and wikitech-l for more input
On Wed, Oct 16, 2013 at 11:22 AM, Arthur Richards <aricha...@wikimedia.org>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 <jforres...@wikimedia.org > > 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 <kw...@wikimedia.org> 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 >>> wmfprod...@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wmfproduct >>> >>> >> >> >> -- >> James D. Forrester >> Product Manager, VisualEditor >> Wikimedia Foundation, Inc. >> >> jforres...@wikimedia.org | @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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
