Work is continuing apace on our new wiki, code named Kuma. However, as work continues, it becomes clear that there will continue to be surprises in terms of things being trickier than expected. As such, it has been decided that we will not, for now, target any specific launch date. Instead, we will have a series of test days to gather feedback on specific areas of the software. These will be announced in advance, at least by email to target audiences, which will vary depending on what needs specific testing.
Broader tests will begin once we get closer to firming up an actual launch.
This process is taking longer than we'd hoped, but obviously it's very important we get this right, given how many people rely heavily on MDN.
> Work is continuing apace on our new wiki, code named Kuma. However, as work continues, it becomes clear that there will continue to be surprises in terms of things being trickier than expected. As such, it has been decided that we will not, for now, target any specific launch date. Instead, we will have a series of test days to gather feedback on specific areas of the software.
Sounds like a good move.
I couldn't make it to the previous test day (I had a friend coming from far this day). Could "test days" be extended to "test weeks" or "test period" or something like that?
It would be easier for me to participate.
What happens between test days or periods? Is the beta Kuma supposed not to be used? Is it open for testing anyway?
Alongside with each launch, could an etherpad be open to share feedback (and be sure that issues are not reported twice)?
It is available for testing in between,or will be (it's complicated; there are multiple test servers in various states right now). The test days are intended for intensive, directed tests.
One thing holding us up right owns the lack of dedicated hardware to test on right now. IT is back logged working on moving us out of the old data center. Things should move faster on the IT front once that's done in a few weeks.
Eric Shepherd
Sent from my iPad
On Apr 26, 2012, at 8:42 AM, David Bruant <bruan...@gmail.com> wrote:
> Le 26/04/2012 14:36, Eric Shepherd a écrit :
>> Work is continuing apace on our new wiki, code named Kuma. However, as work continues, it becomes clear that there will continue to be surprises in terms of things being trickier than expected. As such, it has been decided that we will not, for now, target any specific launch date. Instead, we will have a series of test days to gather feedback on specific areas of the software.
> Sounds like a good move.
> I couldn't make it to the previous test day (I had a friend coming from far this day). Could "test days" be extended to "test weeks" or "test period" or something like that?
> It would be easier for me to participate.
> What happens between test days or periods? Is the beta Kuma supposed not to be used? Is it open for testing anyway?
> Alongside with each launch, could an etherpad be open to share feedback (and be sure that issues are not reported twice)?
Le 26 avril 2012 14:42, David Bruant <bruan...@gmail.com> a écrit :
> Could "test days" be extended to "test weeks" or "test period" or
> something like that?
Because potential tester are dispatched worldwide, it could be good to
define "test day" as a 24 hours period.
> What happens between test days or periods? Is the beta Kuma supposed not
> to be used? Is it open for testing anyway?
FWIW, my opinion is that the test environnement should be available all the
time but only test days guaranty some stability for tests purpose.
Le 26 avril 2012 14:44, Eric Shepherd <esheph...@mozilla.com> a écrit :
> it's complicated; there are multiple test servers in various states right
> now
Yup, it would be easier for every one if it could be possible to have a
canonical environnement : Development -> Staging -> Production. That way,
the Staging server could be use safely for those tests days.
> One thing holding us up right owns the lack of dedicated hardware to test
> on right now. IT is back logged working on moving us out of the old data
> center. Things should move faster on the IT front once that's done in a few
> weeks.
We're developing Kuma in shadow release, so it's already live on both MDN staging (https://developer-stage9.mozilla.org/) and production (though only for specific users, if you want to test in production, let me know and I'll add you to the list).
To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs - the "New Wiki Feature Preview" section. The list of all pages shows the "top 50" pages that we continuously migrate from MindTouch to Kuma. WARNING: The wiki pages on stage9 are from old data and there's also plenty of junk data in there. Whatever edits you make to Kuma pages will be blown away by the next migration run. And there are bugs. It's a staging server, after all. :)
We're using a release train model like Firefox; we release weekly on Tuesday. So, code flows like so:
Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in kuma/master)
Beta/Staging: developer-stage9.mozilla.org (Tuesday)
Release/Production: developer.mozilla.org (next Tuesday after Staging)
Here's a few ways we could do test days:
1. Weekly test day every Friday(?) for the features released to staging on Tuesday
2. Periodic test days (bi-weekly?) for specific user/feature-sets (translation, KumaScript templates, etc.)
3. All of the above
4. Something else
Having said all that, I'll now gladly leave it to Ali to set up the test days however is best for everyone.
> To test Kuma on staging, go to https://developer-stage9.**mozilla.org/docs<https://developer-stage9.mozilla.org/docs>- the "New Wiki Feature Preview" section. The list of all pages shows the
> "top 50" pages that we continuously migrate from MindTouch to Kuma.
> WARNING: The wiki pages on stage9 are from old data and there's also plenty
> of junk data in there. Whatever edits you make to Kuma pages will be blown
> away by the next migration run. And there are bugs. It's a staging server,
> after all. :)
> We're using a release train model like Firefox; we release weekly on
> Tuesday. So, code flows like so:
> Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in
> kuma/master)
> Beta/Staging: developer-stage9.mozilla.org (Tuesday)
> Release/Production: developer.mozilla.org (next Tuesday after Staging)
> Here's a few ways we could do test days:
> 1. Weekly test day every Friday(?) for the features released to staging on
> Tuesday
> 2. Periodic test days (bi-weekly?) for specific user/feature-sets
> (translation, KumaScript templates, etc.)
> 3. All of the above
> 4. Something else
> Having said all that, I'll now gladly leave it to Ali to set up the test
> days however is best for everyone.
Thanks for your thoughts, Sheppy. Two quick thoughts before I make my way through the thread:
*Estimate Precision*
It sounds like what you're describing is the cone of uncertainty <http://www.construx.com/File.ashx?cid=1651>. The development team in this picture is using a waterfall approach to project management (which Kuma is not), but the cone concept is the same. Basically, it is impossible for us to have a perfectly precise (that is, within +/- 1 day) estimate at this time.
However, we do know that our estimates will become more precise over time. When we started the project, realistic estimates could only come within about +/- 10 months. As we got closer, that narrowed down to +/- one quarter. Now, it seems that we can make a good prediction within +/- 2-3 months.
That's what the picture is about. We cannot promise an exact estimate within +/- one day, but we can promise an estimate that is continuously narrowed over time.
*Agile Estimation*
Agile methodologies also use another estimation approach which I really like. Basically, if the agile team knows its development speed (we do) and the difficulty of remaining work (we will), it can make fairly accurate predictions of what features will be completed by a given date using basic algebra.
Rather than explaining it all here, I would recommend reading Mike Cohn's excellent article on the topic. In this article, you can start reading from "what do I propose instead":
> Work is continuing apace on our new wiki, code named Kuma. However, as work continues, it becomes clear that there will continue to be surprises in terms of things being trickier than expected. As such, it has been decided that we will not, for now, target any specific launch date. Instead, we will have a series of test days to gather feedback on specific areas of the software. These will be announced in advance, at least by email to target audiences, which will vary depending on what needs specific testing.
> Broader tests will begin once we get closer to firming up an actual launch.
> This process is taking longer than we'd hoped, but obviously it's very important we get this right, given how many people rely heavily on MDN.
I'm leaning towards option 3 - have smaller, more "informal" test periods after each release that focus on testing a sub-set of code/features that were in a specific release (or bundle 2 releases together, so we test at 2 week intervals as opposed to every week), and then doing a few big test days to really bang on the specific user/feature sets. Thoughts on this approach?
----- Original Message -----
From: "Luke Crouch" <lcro...@mozilla.com>
To: "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Alicia Spivak" <aspi...@mozilla.com>, "Les Orchard" <lorch...@mozilla.com>
Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>
Sent: Thursday, April 26, 2012 7:28:54 AM
Subject: Re: MDN/Kuma development update
We're developing Kuma in shadow release, so it's already live on both MDN staging (https://developer-stage9.mozilla.org/) and production (though only for specific users, if you want to test in production, let me know and I'll add you to the list).
To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs - the "New Wiki Feature Preview" section. The list of all pages shows the "top 50" pages that we continuously migrate from MindTouch to Kuma. WARNING: The wiki pages on stage9 are from old data and there's also plenty of junk data in there. Whatever edits you make to Kuma pages will be blown away by the next migration run. And there are bugs. It's a staging server, after all. :)
We're using a release train model like Firefox; we release weekly on Tuesday. So, code flows like so:
Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in kuma/master)
Beta/Staging: developer-stage9.mozilla.org (Tuesday)
Release/Production: developer.mozilla.org (next Tuesday after Staging)
Here's a few ways we could do test days:
1. Weekly test day every Friday(?) for the features released to staging on Tuesday
2. Periodic test days (bi-weekly?) for specific user/feature-sets (translation, KumaScript templates, etc.)
3. All of the above
4. Something else
Having said all that, I'll now gladly leave it to Ali to set up the test days however is best for everyone.
> I'm leaning towards option 3 - have smaller, more "informal" test periods after each release that focus on testing a sub-set of code/features that were in a specific release (or bundle 2 releases together, so we test at 2 week intervals as opposed to every week), and then doing a few big test days to really bang on the specific user/feature sets. Thoughts on this approach?
> ----- Original Message -----
> From: "Luke Crouch"<lcro...@mozilla.com>
> To: "Jeremie Patonnier"<jeremie.patonn...@gmail.com>, "Alicia Spivak"<aspi...@mozilla.com>, "Les Orchard"<lorch...@mozilla.com>
> Cc: "David Bruant"<bruan...@gmail.com>, "Eric Shepherd"<esheph...@mozilla.com>, "engagement-developers"<engagement-develop...@lists.mozilla.org>
> Sent: Thursday, April 26, 2012 7:28:54 AM
> Subject: Re: MDN/Kuma development update
> We're developing Kuma in shadow release, so it's already live on both
> MDN staging (https://developer-stage9.mozilla.org/) and production
> (though only for specific users, if you want to test in production, let
> me know and I'll add you to the list).
> To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs > - the "New Wiki Feature Preview" section. The list of all pages shows
> the "top 50" pages that we continuously migrate from MindTouch to Kuma.
> WARNING: The wiki pages on stage9 are from old data and there's also
> plenty of junk data in there. Whatever edits you make to Kuma pages will
> be blown away by the next migration run. And there are bugs. It's a
> staging server, after all. :)
> We're using a release train model like Firefox; we release weekly on
> Tuesday. So, code flows like so:
> Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in
> kuma/master)
> Beta/Staging: developer-stage9.mozilla.org (Tuesday)
> Release/Production: developer.mozilla.org (next Tuesday after Staging)
> Here's a few ways we could do test days:
> 1. Weekly test day every Friday(?) for the features released to staging
> on Tuesday
> 2. Periodic test days (bi-weekly?) for specific user/feature-sets
> (translation, KumaScript templates, etc.)
> 3. All of the above
> 4. Something else
> Having said all that, I'll now gladly leave it to Ali to set up the test
> days however is best for everyone.
> Thanks for your thoughts, Sheppy. Two quick thoughts before I make my > way through the thread:
> *Estimate Precision*
> It sounds like what you're describing is the cone of uncertainty > <http://www.construx.com/File.ashx?cid=1651>. The development team in > this picture is using a waterfall approach to project management > (which Kuma is not), but the cone concept is the same. Basically, it > is impossible for us to have a perfectly precise (that is, within +/- > 1 day) estimate at this time.
> However, we do know that our estimates will become more precise over > time. When we started the project, realistic estimates could only come > within about +/- 10 months. As we got closer, that narrowed down to > +/- one quarter. Now, it seems that we can make a good prediction > within +/- 2-3 months.
> That's what the picture is about. We cannot promise an exact estimate > within +/- one day, but we can promise an estimate that is > continuously narrowed over time.
> *Agile Estimation*
> Agile methodologies also use another estimation approach which I > really like. Basically, if the agile team knows its development speed > (we do) and the difficulty of remaining work (we will), it can make > fairly accurate predictions of what features will be completed by a > given date using basic algebra.
> Rather than explaining it all here, I would recommend reading Mike > Cohn's excellent article on the topic. In this article, you can start > reading from "what do I propose instead":
> On 04/26/2012 08:36 AM, Eric Shepherd wrote:
>> Work is continuing apace on our new wiki, code named Kuma. However, >> as work continues, it becomes clear that there will continue to be >> surprises in terms of things being trickier than expected. As such, >> it has been decided that we will not, for now, target any specific >> launch date. Instead, we will have a series of test days to gather >> feedback on specific areas of the software. These will be announced >> in advance, at least by email to target audiences, which will vary >> depending on what needs specific testing.
>> Broader tests will begin once we get closer to firming up an actual >> launch.
>> This process is taking longer than we'd hoped, but obviously it's >> very important we get this right, given how many people rely heavily >> on MDN.
I suggest we have informal test periods on staging before releases for smaller featues ( usually on Friday) and schedule bigger test days for multiple features on production.
From: "Luke Crouch" <lcro...@mozilla.com> To: "Ali Spivak" <aspi...@mozilla.com>
Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Les Orchard" <lorch...@mozilla.com>, "Raymond Etornam" <retor...@mozilla.com> Sent: Thursday, April 26, 2012 11:04:44 AM Subject: Re: MDN/Kuma development update
I like that idea. I'm cc'ing Raymond since he's probably not on the list. He'll organize the WebQA stuff.
Raymond, what do you think - informal test periods after releases AND a couple of big test days?
-L
On 4/26/12 11:46 AM, Ali Spivak wrote: > I'm leaning towards option 3 - have smaller, more "informal" test periods after each release that focus on testing a sub-set of code/features that were in a specific release (or bundle 2 releases together, so we test at 2 week intervals as opposed to every week), and then doing a few big test days to really bang on the specific user/feature sets. Thoughts on this approach?
> ----- Original Message ----- > From: "Luke Crouch"<lcro...@mozilla.com> > To: "Jeremie Patonnier"<jeremie.patonn...@gmail.com>, "Alicia Spivak"<aspi...@mozilla.com>, "Les Orchard"<lorch...@mozilla.com> > Cc: "David Bruant"<bruan...@gmail.com>, "Eric Shepherd"<esheph...@mozilla.com>, "engagement-developers"<engagement-develop...@lists.mozilla.org> > Sent: Thursday, April 26, 2012 7:28:54 AM > Subject: Re: MDN/Kuma development update
> We're developing Kuma in shadow release, so it's already live on both > MDN staging (https://developer-stage9.mozilla.org/) and production > (though only for specific users, if you want to test in production, let > me know and I'll add you to the list).
> To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs > - the "New Wiki Feature Preview" section. The list of all pages shows > the "top 50" pages that we continuously migrate from MindTouch to Kuma. > WARNING: The wiki pages on stage9 are from old data and there's also > plenty of junk data in there. Whatever edits you make to Kuma pages will > be blown away by the next migration run. And there are bugs. It's a > staging server, after all. :)
> We're using a release train model like Firefox; we release weekly on > Tuesday. So, code flows like so:
> Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in > kuma/master) > Beta/Staging: developer-stage9.mozilla.org (Tuesday) > Release/Production: developer.mozilla.org (next Tuesday after Staging)
> Here's a few ways we could do test days:
> 1. Weekly test day every Friday(?) for the features released to staging > on Tuesday > 2. Periodic test days (bi-weekly?) for specific user/feature-sets > (translation, KumaScript templates, etc.) > 3. All of the above > 4. Something else
> Having said all that, I'll now gladly leave it to Ali to set up the test > days however is best for everyone.
Hey David. Your ideas are spot on. I documented a very similar process <https://groups.google.com/group/mozilla.dev.mdn/browse_thread/thread/...> right before my internship ended. Because my part-time work didn't kick in until months after that, I was never able to actually carry it out.
Unless there are any objections, I'll plan to spin that up as soon as the current Sprint ends.
> Le 26/04/2012 14:36, Eric Shepherd a écrit :
>> Work is continuing apace on our new wiki, code named Kuma. However, >> as work continues, it becomes clear that there will continue to be >> surprises in terms of things being trickier than expected. As such, >> it has been decided that we will not, for now, target any specific >> launch date. Instead, we will have a series of test days to gather >> feedback on specific areas of the software.
> Sounds like a good move.
> I couldn't make it to the previous test day (I had a friend coming > from far this day). Could "test days" be extended to "test weeks" or > "test period" or something like that?
> It would be easier for me to participate.
> What happens between test days or periods? Is the beta Kuma supposed > not to be used? Is it open for testing anyway?
> Alongside with each launch, could an etherpad be open to share > feedback (and be sure that issues are not reported twice)?
I will be the first to admit I am still learning about agile and Scrum. In my class this quarter, I realized that we are missing something big: a distinction between user stories (real feature plans that users can point to) and low-level development tasks.
In more traditional Scrum, the product backlog is composed of user stories only. At each sprint, the team chooses some number of user stories to complete (maybe 5-7) and then writes down a few low-level development tasks that they must do for each user story to complete it. For example, the product backlog could look something like this:
* As a localizer, I want a list of articles that need localization, so
that I can discover them easily. [10 points]
o Write logic for finding articles that need localization [.5 hours]
o Design page [4 hours]
o Write HTML/CSS for page [3 hours]
* As a technical writer, I want to "follow" certain users, so that I
can keep a close eye on people who usually make mistakes.
o Update the /users/ table with a column called /following/ [1 hour]
o Add buttons for following and unfollowing users [2 hours]
o Update dashboard page to show recent changes from followed users
[5 hours]
* etc.
The biggest benefit of an approach like this is that it gives users real insight into the project. Rather than seeing lots of little development tasks being completed, they see real tangible features being completed. Additionally, estimation is easier, since only the handful of top-level user stories need to be estimated using planning poker.
Of course, this is strict Scrum. We could adapt as necessary, but I think the benefits are appealing enough that the approach is worth considering. Thoughts?
> That way we have a rough idea of the overall remaining workload. > Though of course that will expand as bugs are caught in test days.
> -L
> On 4/26/12 10:53 AM, John Karahalis wrote:
>> Thanks for your thoughts, Sheppy. Two quick thoughts before I make my >> way through the thread:
>> *Estimate Precision*
>> It sounds like what you're describing is the cone of uncertainty >> <http://www.construx.com/File.ashx?cid=1651>. The development team in >> this picture is using a waterfall approach to project management >> (which Kuma is not), but the cone concept is the same. Basically, it >> is impossible for us to have a perfectly precise (that is, within +/- >> 1 day) estimate at this time.
>> However, we do know that our estimates will become more precise over >> time. When we started the project, realistic estimates could only >> come within about +/- 10 months. As we got closer, that narrowed down >> to +/- one quarter. Now, it seems that we can make a good prediction >> within +/- 2-3 months.
>> That's what the picture is about. We cannot promise an exact estimate >> within +/- one day, but we can promise an estimate that is >> continuously narrowed over time.
>> *Agile Estimation*
>> Agile methodologies also use another estimation approach which I >> really like. Basically, if the agile team knows its development speed >> (we do) and the difficulty of remaining work (we will), it can make >> fairly accurate predictions of what features will be completed by a >> given date using basic algebra.
>> Rather than explaining it all here, I would recommend reading Mike >> Cohn's excellent article on the topic. In this article, you can start >> reading from "what do I propose instead":
>> On 04/26/2012 08:36 AM, Eric Shepherd wrote:
>>> Work is continuing apace on our new wiki, code named Kuma. However, >>> as work continues, it becomes clear that there will continue to be >>> surprises in terms of things being trickier than expected. As such, >>> it has been decided that we will not, for now, target any specific >>> launch date. Instead, we will have a series of test days to gather >>> feedback on specific areas of the software. These will be announced >>> in advance, at least by email to target audiences, which will vary >>> depending on what needs specific testing.
>>> Broader tests will begin once we get closer to firming up an actual >>> launch.
>>> This process is taking longer than we'd hoped, but obviously it's >>> very important we get this right, given how many people rely heavily >>> on MDN.
Before we had agile project management, we had plan-driven project management. People planned everything up front, built the software, and then tested it at the very end. The result? Lots of unused features and many users saying things like "Oh, that's not really what we wanted."
Agile embraces change. It encourages users to play with the software as often as they can, so that their feedback can be taken into account before a small miscommunications become a major problems.
This has been missing in our approach, and I take responsibility for not doing more about it over the summer. For now, the sooner and more regularly we can get people to play with the software (ideally after every release), the better.
> I'm leaning towards option 3 - have smaller, more "informal" test periods after each release that focus on testing a sub-set of code/features that were in a specific release (or bundle 2 releases together, so we test at 2 week intervals as opposed to every week), and then doing a few big test days to really bang on the specific user/feature sets. Thoughts on this approach?
> ----- Original Message -----
> From: "Luke Crouch"<lcro...@mozilla.com>
> To: "Jeremie Patonnier"<jeremie.patonn...@gmail.com>, "Alicia Spivak"<aspi...@mozilla.com>, "Les Orchard"<lorch...@mozilla.com>
> Cc: "David Bruant"<bruan...@gmail.com>, "Eric Shepherd"<esheph...@mozilla.com>, "engagement-developers"<engagement-develop...@lists.mozilla.org>
> Sent: Thursday, April 26, 2012 7:28:54 AM
> Subject: Re: MDN/Kuma development update
> We're developing Kuma in shadow release, so it's already live on both
> MDN staging (https://developer-stage9.mozilla.org/) and production
> (though only for specific users, if you want to test in production, let
> me know and I'll add you to the list).
> To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs > - the "New Wiki Feature Preview" section. The list of all pages shows
> the "top 50" pages that we continuously migrate from MindTouch to Kuma.
> WARNING: The wiki pages on stage9 are from old data and there's also
> plenty of junk data in there. Whatever edits you make to Kuma pages will
> be blown away by the next migration run. And there are bugs. It's a
> staging server, after all. :)
> We're using a release train model like Firefox; we release weekly on
> Tuesday. So, code flows like so:
> Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in
> kuma/master)
> Beta/Staging: developer-stage9.mozilla.org (Tuesday)
> Release/Production: developer.mozilla.org (next Tuesday after Staging)
> Here's a few ways we could do test days:
> 1. Weekly test day every Friday(?) for the features released to staging
> on Tuesday
> 2. Periodic test days (bi-weekly?) for specific user/feature-sets
> (translation, KumaScript templates, etc.)
> 3. All of the above
> 4. Something else
> Having said all that, I'll now gladly leave it to Ali to set up the test
> days however is best for everyone.
> Hey David. Your ideas are spot on. I documented a very similar process > <https://groups.google.com/group/mozilla.dev.mdn/browse_thread/thread/...> > right before my internship ended. Because my part-time work didn't > kick in until months after that, I was never able to actually carry it > out.
> Unless there are any objections, I'll plan to spin that up as soon as > the current Sprint ends.
> On 04/26/2012 08:42 AM, David Bruant wrote:
>> Le 26/04/2012 14:36, Eric Shepherd a écrit :
>>> Work is continuing apace on our new wiki, code named Kuma. However, >>> as work continues, it becomes clear that there will continue to be >>> surprises in terms of things being trickier than expected. As such, >>> it has been decided that we will not, for now, target any specific >>> launch date. Instead, we will have a series of test days to gather >>> feedback on specific areas of the software.
>> Sounds like a good move.
>> I couldn't make it to the previous test day (I had a friend coming >> from far this day). Could "test days" be extended to "test weeks" or >> "test period" or something like that?
>> It would be easier for me to participate.
>> What happens between test days or periods? Is the beta Kuma supposed >> not to be used? Is it open for testing anyway?
>> Alongside with each launch, could an etherpad be open to share >> feedback (and be sure that issues are not reported twice)?
as a newbie & having a bit of experience with scrum/agile, I like the idea. It would make it much easier for me to understand how each bug corresponds to the feature list, and help in a lot of areas, such as tracking how we are progressing with each feature, prioritizing, and communicating where we are to the community. It would also help me organize test days because it would be clear which features are fully developed and which are still in progress in each sprint.
I am guessing we would possibly modify to make sure we don't derail ongoing work in an effort to implement this, but I'm happy to take this on with John and pull in the rest of the team for validation as needed. I have also been pondering setting up a few hours devoted to going through what still needs to be done and how it would fit into the various stories (features), and also figuring out what left to do before we feel comfortable setting a date for release, and what is required for the actual release itself. Could all be done simultaneously...
----- Original Message -----
From: "John Karahalis" <jkaraha...@mozilla.com>
To: "Luke Crouch" <lcro...@mozilla.com>
Cc: engagement-develop...@lists.mozilla.org
Sent: Thursday, April 26, 2012 1:21:27 PM
Subject: Re: MDN/Kuma development update
Absolutely, yes.
I will be the first to admit I am still learning about agile and Scrum. In my class this quarter, I realized that we are missing something big: a distinction between user stories (real feature plans that users can point to) and low-level development tasks.
In more traditional Scrum, the product backlog is composed of user stories only. At each sprint, the team chooses some number of user stories to complete (maybe 5-7) and then writes down a few low-level development tasks that they must do for each user story to complete it. For example, the product backlog could look something like this:
* As a localizer, I want a list of articles that need localization, so
that I can discover them easily. [10 points]
o Write logic for finding articles that need localization [.5 hours]
o Design page [4 hours]
o Write HTML/CSS for page [3 hours]
* As a technical writer, I want to "follow" certain users, so that I
can keep a close eye on people who usually make mistakes.
o Update the /users/ table with a column called /following/ [1 hour]
o Add buttons for following and unfollowing users [2 hours]
o Update dashboard page to show recent changes from followed users
[5 hours]
* etc.
The biggest benefit of an approach like this is that it gives users real insight into the project. Rather than seeing lots of little development tasks being completed, they see real tangible features being completed. Additionally, estimation is easier, since only the handful of top-level user stories need to be estimated using planning poker.
Of course, this is strict Scrum. We could adapt as necessary, but I think the benefits are appealing enough that the approach is worth considering. Thoughts?
> That way we have a rough idea of the overall remaining workload. > Though of course that will expand as bugs are caught in test days.
> -L
> On 4/26/12 10:53 AM, John Karahalis wrote:
>> Thanks for your thoughts, Sheppy. Two quick thoughts before I make my >> way through the thread:
>> *Estimate Precision*
>> It sounds like what you're describing is the cone of uncertainty >> <http://www.construx.com/File.ashx?cid=1651>. The development team in >> this picture is using a waterfall approach to project management >> (which Kuma is not), but the cone concept is the same. Basically, it >> is impossible for us to have a perfectly precise (that is, within +/- >> 1 day) estimate at this time.
>> However, we do know that our estimates will become more precise over >> time. When we started the project, realistic estimates could only >> come within about +/- 10 months. As we got closer, that narrowed down >> to +/- one quarter. Now, it seems that we can make a good prediction >> within +/- 2-3 months.
>> That's what the picture is about. We cannot promise an exact estimate >> within +/- one day, but we can promise an estimate that is >> continuously narrowed over time.
>> *Agile Estimation*
>> Agile methodologies also use another estimation approach which I >> really like. Basically, if the agile team knows its development speed >> (we do) and the difficulty of remaining work (we will), it can make >> fairly accurate predictions of what features will be completed by a >> given date using basic algebra.
>> Rather than explaining it all here, I would recommend reading Mike >> Cohn's excellent article on the topic. In this article, you can start >> reading from "what do I propose instead":
>> On 04/26/2012 08:36 AM, Eric Shepherd wrote:
>>> Work is continuing apace on our new wiki, code named Kuma. However, >>> as work continues, it becomes clear that there will continue to be >>> surprises in terms of things being trickier than expected. As such, >>> it has been decided that we will not, for now, target any specific >>> launch date. Instead, we will have a series of test days to gather >>> feedback on specific areas of the software. These will be announced >>> in advance, at least by email to target audiences, which will vary >>> depending on what needs specific testing.
>>> Broader tests will begin once we get closer to firming up an actual >>> launch.
>>> This process is taking longer than we'd hoped, but obviously it's >>> very important we get this right, given how many people rely heavily >>> on MDN.
Breaking down into so many artifacts adds more overhead than we've been able to handle so far. But it will be more important to plan from the user's perspective as we release to the users more often now. And now we have John and Ali to help out.
> I will be the first to admit I am still learning about agile and > Scrum. In my class this quarter, I realized that we are missing > something big: a distinction between user stories (real feature plans > that users can point to) and low-level development tasks.
> In more traditional Scrum, the product backlog is composed of user > stories only. At each sprint, the team chooses some number of user > stories to complete (maybe 5-7) and then writes down a few low-level > development tasks that they must do for each user story to complete > it. For example, the product backlog could look something like this:
> * As a localizer, I want a list of articles that need localization,
> so that I can discover them easily. [10 points]
> o Write logic for finding articles that need localization [.5 hours]
> o Design page [4 hours]
> o Write HTML/CSS for page [3 hours]
> * As a technical writer, I want to "follow" certain users, so that I
> can keep a close eye on people who usually make mistakes.
> o Update the /users/ table with a column called /following/ [1 hour]
> o Add buttons for following and unfollowing users [2 hours]
> o Update dashboard page to show recent changes from followed
> users [5 hours]
> * etc.
> The biggest benefit of an approach like this is that it gives users > real insight into the project. Rather than seeing lots of little > development tasks being completed, they see real tangible features > being completed. Additionally, estimation is easier, since only the > handful of top-level user stories need to be estimated using planning > poker.
> Of course, this is strict Scrum. We could adapt as necessary, but I > think the benefits are appealing enough that the approach is worth > considering. Thoughts?
>> That way we have a rough idea of the overall remaining workload. >> Though of course that will expand as bugs are caught in test days.
>> -L
>> On 4/26/12 10:53 AM, John Karahalis wrote:
>>> Thanks for your thoughts, Sheppy. Two quick thoughts before I make >>> my way through the thread:
>>> *Estimate Precision*
>>> It sounds like what you're describing is the cone of uncertainty >>> <http://www.construx.com/File.ashx?cid=1651>. The development team >>> in this picture is using a waterfall approach to project management >>> (which Kuma is not), but the cone concept is the same. Basically, it >>> is impossible for us to have a perfectly precise (that is, within >>> +/- 1 day) estimate at this time.
>>> However, we do know that our estimates will become more precise over >>> time. When we started the project, realistic estimates could only >>> come within about +/- 10 months. As we got closer, that narrowed >>> down to +/- one quarter. Now, it seems that we can make a good >>> prediction within +/- 2-3 months.
>>> That's what the picture is about. We cannot promise an exact >>> estimate within +/- one day, but we can promise an estimate that is >>> continuously narrowed over time.
>>> *Agile Estimation*
>>> Agile methodologies also use another estimation approach which I >>> really like. Basically, if the agile team knows its development >>> speed (we do) and the difficulty of remaining work (we will), it can >>> make fairly accurate predictions of what features will be completed >>> by a given date using basic algebra.
>>> Rather than explaining it all here, I would recommend reading Mike >>> Cohn's excellent article on the topic. In this article, you can >>> start reading from "what do I propose instead":
>>> On 04/26/2012 08:36 AM, Eric Shepherd wrote:
>>>> Work is continuing apace on our new wiki, code named Kuma. However, >>>> as work continues, it becomes clear that there will continue to be >>>> surprises in terms of things being trickier than expected. As such, >>>> it has been decided that we will not, for now, target any specific >>>> launch date. Instead, we will have a series of test days to gather >>>> feedback on specific areas of the software. These will be announced >>>> in advance, at least by email to target audiences, which will vary >>>> depending on what needs specific testing.
>>>> Broader tests will begin once we get closer to firming up an actual >>>> launch.
>>>> This process is taking longer than we'd hoped, but obviously it's >>>> very important we get this right, given how many people rely >>>> heavily on MDN.
>>>> Eric Shepherd
>>>> Sent from my iPad
>>>> _______________________________________________
>>>> engagement-developers mailing list
>>>> engagement-develop...@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/engagement-developers
> -- > John Karahalis
> Developer Engagement
> @openjck
So, how about we shoot for something like the following:
smaller, "informal" testing periods (24-48 hours) of a specific code release: May 4, May 18, June 8, June 15
Organized feature test days: June 1 & June 22
----- Original Message -----
From: "Raymond Etornam Agbeame" <retor...@mozilla.com>
To: "Luke Crouch" <lcro...@mozilla.com>
Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Les Orchard" <lorch...@mozilla.com>, "Ali Spivak" <aspi...@mozilla.com>
Sent: Thursday, April 26, 2012 11:29:38 AM
Subject: Re: MDN/Kuma development update
Hi All,
I suggest we have informal test periods on staging before releases for smaller featues ( usually on Friday) and schedule bigger test days for multiple features on production.
Raymond
----- Original Message -----
From: "Luke Crouch" <lcro...@mozilla.com> To: "Ali Spivak" <aspi...@mozilla.com> Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Les Orchard" <lorch...@mozilla.com>, "Raymond Etornam" <retor...@mozilla.com> Sent: Thursday, April 26, 2012 11:04:44 AM Subject: Re: MDN/Kuma development update
I like that idea. I'm cc'ing Raymond since he's probably not on the list. He'll organize the WebQA stuff.
Raymond, what do you think - informal test periods after releases AND a couple of big test days?
-L
On 4/26/12 11:46 AM, Ali Spivak wrote: > I'm leaning towards option 3 - have smaller, more "informal" test periods after each release that focus on testing a sub-set of code/features that were in a specific release (or bundle 2 releases together, so we test at 2 week intervals as opposed to every week), and then doing a few big test days to really bang on the specific user/feature sets. Thoughts on this approach?
> ----- Original Message ----- > From: "Luke Crouch"<lcro...@mozilla.com> > To: "Jeremie Patonnier"<jeremie.patonn...@gmail.com>, "Alicia Spivak"<aspi...@mozilla.com>, "Les Orchard"<lorch...@mozilla.com> > Cc: "David Bruant"<bruan...@gmail.com>, "Eric Shepherd"<esheph...@mozilla.com>, "engagement-developers"<engagement-develop...@lists.mozilla.org> > Sent: Thursday, April 26, 2012 7:28:54 AM > Subject: Re: MDN/Kuma development update
> We're developing Kuma in shadow release, so it's already live on both > MDN staging (https://developer-stage9.mozilla.org/) and production > (though only for specific users, if you want to test in production, let > me know and I'll add you to the list).
> To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs > - the "New Wiki Feature Preview" section. The list of all pages shows > the "top 50" pages that we continuously migrate from MindTouch to Kuma. > WARNING: The wiki pages on stage9 are from old data and there's also > plenty of junk data in there. Whatever edits you make to Kuma pages will > be blown away by the next migration run. And there are bugs. It's a > staging server, after all. :)
> We're using a release train model like Firefox; we release weekly on > Tuesday. So, code flows like so:
> Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in > kuma/master) > Beta/Staging: developer-stage9.mozilla.org (Tuesday) > Release/Production: developer.mozilla.org (next Tuesday after Staging)
> Here's a few ways we could do test days:
> 1. Weekly test day every Friday(?) for the features released to staging > on Tuesday > 2. Periodic test days (bi-weekly?) for specific user/feature-sets > (translation, KumaScript templates, etc.) > 3. All of the above > 4. Something else
> Having said all that, I'll now gladly leave it to Ali to set up the test > days however is best for everyone.
> So, how about we shoot for something like the following:
> smaller, "informal" testing periods (24-48 hours) of a specific code release: May 4, May 18, June 8, June 15
> Organized feature test days: June 1 & June 22
FWIW, May 4th will see many webdevs (including me) on planes traveling back home from a webdev offsite taking place all next week. That also means we probably won't get much productive work done over the next week to show off at a test day.
From: "Ali Spivak" <aspi...@mozilla.com> To: "Raymond Etornam Agbeame" <retor...@mozilla.com>
Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Les Orchard" <lorch...@mozilla.com>, "Luke Crouch" <lcro...@mozilla.com> Sent: Friday, April 27, 2012 11:14:49 AM Subject: Re: MDN/Kuma development update
So, how about we shoot for something like the following:
smaller, "informal" testing periods (24-48 hours) of a specific code release: May 4, May 18, June 8, June 15 Organized feature test days: June 1 & June 22
----- Original Message ----- From: "Raymond Etornam Agbeame" <retor...@mozilla.com> To: "Luke Crouch" <lcro...@mozilla.com> Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Les Orchard" <lorch...@mozilla.com>, "Ali Spivak" <aspi...@mozilla.com> Sent: Thursday, April 26, 2012 11:29:38 AM Subject: Re: MDN/Kuma development update
Hi All,
I suggest we have informal test periods on staging before releases for smaller featues ( usually on Friday) and schedule bigger test days for multiple features on production.
Raymond
----- Original Message -----
From: "Luke Crouch" <lcro...@mozilla.com> To: "Ali Spivak" <aspi...@mozilla.com> Cc: "David Bruant" <bruan...@gmail.com>, "Eric Shepherd" <esheph...@mozilla.com>, "engagement-developers" <engagement-develop...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie.patonn...@gmail.com>, "Les Orchard" <lorch...@mozilla.com>, "Raymond Etornam" <retor...@mozilla.com> Sent: Thursday, April 26, 2012 11:04:44 AM Subject: Re: MDN/Kuma development update
I like that idea. I'm cc'ing Raymond since he's probably not on the list. He'll organize the WebQA stuff.
Raymond, what do you think - informal test periods after releases AND a couple of big test days?
-L
On 4/26/12 11:46 AM, Ali Spivak wrote: > I'm leaning towards option 3 - have smaller, more "informal" test periods after each release that focus on testing a sub-set of code/features that were in a specific release (or bundle 2 releases together, so we test at 2 week intervals as opposed to every week), and then doing a few big test days to really bang on the specific user/feature sets. Thoughts on this approach?
> ----- Original Message ----- > From: "Luke Crouch"<lcro...@mozilla.com> > To: "Jeremie Patonnier"<jeremie.patonn...@gmail.com>, "Alicia Spivak"<aspi...@mozilla.com>, "Les Orchard"<lorch...@mozilla.com> > Cc: "David Bruant"<bruan...@gmail.com>, "Eric Shepherd"<esheph...@mozilla.com>, "engagement-developers"<engagement-develop...@lists.mozilla.org> > Sent: Thursday, April 26, 2012 7:28:54 AM > Subject: Re: MDN/Kuma development update
> We're developing Kuma in shadow release, so it's already live on both > MDN staging (https://developer-stage9.mozilla.org/) and production > (though only for specific users, if you want to test in production, let > me know and I'll add you to the list).
> To test Kuma on staging, go to https://developer-stage9.mozilla.org/docs > - the "New Wiki Feature Preview" section. The list of all pages shows > the "top 50" pages that we continuously migrate from MindTouch to Kuma. > WARNING: The wiki pages on stage9 are from old data and there's also > plenty of junk data in there. Whatever edits you make to Kuma pages will > be blown away by the next migration run. And there are bugs. It's a > staging server, after all. :)
> We're using a release train model like Firefox; we release weekly on > Tuesday. So, code flows like so:
> Nightly/Development: kuma-stage.mozilla.org (5 minutes after landing in > kuma/master) > Beta/Staging: developer-stage9.mozilla.org (Tuesday) > Release/Production: developer.mozilla.org (next Tuesday after Staging)
> Here's a few ways we could do test days:
> 1. Weekly test day every Friday(?) for the features released to staging > on Tuesday > 2. Periodic test days (bi-weekly?) for specific user/feature-sets > (translation, KumaScript templates, etc.) > 3. All of the above > 4. Something else
> Having said all that, I'll now gladly leave it to Ali to set up the test > days however is best for everyone.
On 4/27/12 2:14 PM, Ali Spivak wrote:
> So, how about we shoot for something like the following:
> smaller, "informal" testing periods (24-48 hours) of a specific code release: May 4, May 18, June 8, June 15
> Organized feature test days: June 1 & June 22
FWIW, May 4th will see many webdevs (including me) on planes traveling back home from a webdev offsite taking place all next week. That also means we probably won't get much productive work done over the next week to show off at a test day.
I'm more impatient than Les, so I vote for a small test day testing very basic features on May 4th. We'll have a nice little pile of fresh bugs for the next sprint.
> On 4/27/12 2:14 PM, Ali Spivak wrote:
>> So, how about we shoot for something like the following:
>> smaller, "informal" testing periods (24-48 hours) of a specific code >> release: May 4, May 18, June 8, June 15
>> Organized feature test days: June 1 & June 22
> FWIW, May 4th will see many webdevs (including me) on planes traveling > back home from a webdev offsite taking place all next week. That also > means we probably won't get much productive work done over the next > week to show off at a test day.
> I'm more impatient than Les, so I vote for a small test day testing very
> basic features on May 4th. We'll have a nice little pile of fresh bugs
> for the next sprint.
It's not patience, so much as it would be nice to have the whole team on board for a test day. Just as a general principle, anyway.
That, and I'm hoping to take most of next week to catch up with the rest of webdev since it only happens once a year or so.
> On 4/27/12 1:17 PM, Les Orchard wrote:
>> On 4/27/12 2:14 PM, Ali Spivak wrote:
>>> So, how about we shoot for something like the following:
>>> smaller, "informal" testing periods (24-48 hours) of a specific code
>>> release: May 4, May 18, June 8, June 15
>>> Organized feature test days: June 1 & June 22
>> FWIW, May 4th will see many webdevs (including me) on planes traveling
>> back home from a webdev offsite taking place all next week. That also
>> means we probably won't get much productive work done over the next
>> week to show off at a test day.
> I'm more impatient than Les, so I vote for a small test day testing very
> basic features on May 4th. We'll have a nice little pile of fresh bugs
> for the next sprint.
Actually, aren't you yourself on a plane back home that day, too? Who *would* be around for the test day? If no devs... how would that work?
> On 4/27/12 6:22 PM, Luke Crouch wrote:
>> I'm more impatient than Les, so I vote for a small test day testing very
>> basic features on May 4th. We'll have a nice little pile of fresh bugs
>> for the next sprint.
> Actually, aren't you yourself on a plane back home that day, too? Who > *would* be around for the test day? If no devs... how would that work?
The potential users. We'd bang on the server and then complain about you behind your back.
