[teampractices] [Product] Bugs on the deployment train

[Arthur Richards]

+teampractices and wikitech-l for more input


On Wed, Oct 16, 2013 at 11:22 AM, Arthur Richards
<arichards at 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 <jforrester at 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 <kwang at 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
>>> Wmfproduct at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wmfproduct
>>>
>>>
>>
>>
>> --
>> James D. Forrester
>> Product Manager, VisualEditor
>> Wikimedia Foundation, Inc.
>>
>> jforrester at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wikimedia.org/pipermail/teampractices/attachments/20131017/4889fcb1/attachment.html>