+teampractices and wikitech-l for more input
On Wed, Oct 16, 2013 at 11:22 AM, Arthur Richards arichards@wikimedia.orgwrote:
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfproduct
-- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
-- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687
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 arichards@wikimedia.orgwrote:
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wmfproduct
-- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@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
teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
wikitech-l@lists.wikimedia.org