MDN/Kuma development update

[Eric Shepherd]

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

[David Bruant]

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)?

David

[Eric Shepherd]

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

[Jeremie Patonnier]

Hi,

Le 26 avril 2012 14:42, David Bruant <brua...@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 <eshe...@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.

That's good news :D

--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Luke Crouch]

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'll soon have a (working) dev server at https://kuma-stage.mozilla.org/

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.

/me goes back to fixing kuma-stage.mozilla.org

-L

[Jeremie Patonnier]

Thanks luke,

it's much more clearer for an outsider like me (^_^)

Cheers
Jérémie

Le 26 avril 2012 16:28, Luke Crouch <lcr...@mozilla.com> a écrit :

> We're developing Kuma in shadow release, so it's already live on both MDN

> staging (https://developer-stage9.**mozilla.org/<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<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'll soon have a (working) dev server at https://kuma-stage.mozilla.**
> org/ <https://kuma-stage.mozilla.org/>

>
> 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.
>
> /me goes back to fixing kuma-stage.mozilla.org
>
> -L
>

[John Karahalis]

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":

http://www.mountaingoatsoftware.com/blog/why-there-should-not-be-a-release-backlog

The (very helpful) images aren't showing up for me, but you can see the
thumbnails here:

https://encrypted.google.com/search?q=mike+cohn+velocity&hl=en&prmd=imvnso&source=lnms&tbm=isch&ei=ZW6ZT4ujM6j26AHIquH1Bg&sa=X&oi=mode_link&ct=mode&cd=2&ved=0CAkQ_AUoAQ&biw=800&bih=752#hl=en&tbm=isch&sa=1&q=mike+cohn+velocity+average&oq=mike+cohn+velocity+average&aq=f&aqi=&aql=&gs_nf=1&gs_l=img.3...32238.33140.0.33258.8.8.0.7.0.0.68.68.1.1.0.PeebJLXVPXw&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=779f1a33154628dd&biw=1600&bih=781

> Eric Shepherd
> Sent from my iPad

> _______________________________________________
> engagement-developers mailing list
> engagement...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/engagement-developers

--
John Karahalis
Developer Engagement
@openjck

[Ali Spivak]

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" <lcr...@mozilla.com>
To: "Jeremie Patonnier" <jeremie....@gmail.com>, "Alicia Spivak" <asp...@mozilla.com>, "Les Orchard" <lorc...@mozilla.com>
Cc: "David Bruant" <brua...@gmail.com>, "Eric Shepherd" <eshe...@mozilla.com>, "engagement-developers" <engagement...@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'll soon have a (working) dev server at https://kuma-stage.mozilla.org/

[Luke Crouch]

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

[Luke Crouch]

Very cool. Would be great to get rough estimates for the first level of
bugs in
https://bugzilla.mozilla.org/showdependencytree.cgi?id=710713&hide_resolved=1

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

[Raymond Etornam Agbeame]

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

[John Karahalis]

Hey David. Your ideas are spot on. I documented a very similar process
<https://groups.google.com/group/mozilla.dev.mdn/browse_thread/thread/8b1c1c34a30432bc?pli=1>
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)?
>
> David

> _______________________________________________
> engagement-developers mailing list
> engagement...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/engagement-developers

[John Karahalis]

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?

>>> 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

[John Karahalis]

I think those are all great ideas.

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.

[John Karahalis]

Sent this before I realized there was a detailed discussion about our
testing approach.

The feedback process
<https://groups.google.com/d/msg/mozilla.dev.mdn/ixwcNKMEMrw/uDOughYVFcIJ>
I wrote up over the summer captures many of these ideas. Building off of
that that and today's discussions, is there anything specifically that
we would like to change about that process?

On 04/26/2012 03:42 PM, John Karahalis wrote:
> Hey David. Your ideas are spot on. I documented a very similar process
> <https://groups.google.com/group/mozilla.dev.mdn/browse_thread/thread/8b1c1c34a30432bc?pli=1>
> 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)?
>>
>> David

[Ali Spivak]

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...

ali

----- Original Message -----
From: "John Karahalis" <jkara...@mozilla.com>
To: "Luke Crouch" <lcr...@mozilla.com>
Cc: engagement...@lists.mozilla.org
Sent: Thursday, April 26, 2012 1:21:27 PM
Subject: Re: MDN/Kuma development update

>>> 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

[Luke Crouch]

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.

-L

[Ali Spivak]

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" <reto...@mozilla.com>
To: "Luke Crouch" <lcr...@mozilla.com>
Cc: "David Bruant" <brua...@gmail.com>, "Eric Shepherd" <eshe...@mozilla.com>, "engagement-developers" <engagement...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie....@gmail.com>, "Les Orchard" <lorc...@mozilla.com>, "Ali Spivak" <asp...@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" <lcr...@mozilla.com>
To: "Ali Spivak" <asp...@mozilla.com>
Cc: "David Bruant" <brua...@gmail.com>, "Eric Shepherd" <eshe...@mozilla.com>, "engagement-developers" <engagement...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie....@gmail.com>, "Les Orchard" <lorc...@mozilla.com>, "Raymond Etornam" <reto...@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"<lcr...@mozilla.com>
> To: "Jeremie Patonnier"<jeremie....@gmail.com>, "Alicia Spivak"<asp...@mozilla.com>, "Les Orchard"<lorc...@mozilla.com>

> Cc: "David Bruant"<brua...@gmail.com>, "Eric Shepherd"<eshe...@mozilla.com>, "engagement-developers"<engagement...@lists.mozilla.org>
> Sent: Thursday, April 26, 2012 7:28:54 AM
> Subject: Re: MDN/Kuma development update
>

[Les Orchard]

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.

--
lorc...@mozilla.com
http://lmorchard.com
{web,mad,computer} scientist

[Raymond Etornam Agbeame]

+1 to that .

Raymond

----- Original Message -----

From: "Ali Spivak" <asp...@mozilla.com>
To: "Raymond Etornam Agbeame" <reto...@mozilla.com>
Cc: "David Bruant" <brua...@gmail.com>, "Eric Shepherd" <eshe...@mozilla.com>, "engagement-developers" <engagement...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie....@gmail.com>, "Les Orchard" <lorc...@mozilla.com>, "Luke Crouch" <lcr...@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

[Ali Spivak]

ah, ok!

So, given the offsite, do we want to do the first one on May 11th or 18th?

----- Original Message -----
From: "Les Orchard" <lorc...@mozilla.com>
To: "Ali Spivak" <asp...@mozilla.com>
Cc: "Raymond Etornam Agbeame" <reto...@mozilla.com>, "David Bruant" <brua...@gmail.com>, "Eric Shepherd" <eshe...@mozilla.com>, "engagement-developers" <engagement...@lists.mozilla.org>, "Jeremie Patonnier" <jeremie....@gmail.com>, "Luke Crouch" <lcr...@mozilla.com>
Sent: Friday, April 27, 2012 11:17:20 AM
Subject: Re: MDN/Kuma development update

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

[Luke Crouch]

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.

-L

[Les Orchard]

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.

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.
>>

[Les Orchard]

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?

[Janet Swisher]

On 4/27/12 3:32 PM, Les Orchard wrote:
> 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.

--Janet

[Luke Crouch]

+1

It might actually be better to have some users bang on it without dev
hand-holding - more like real-life users that way. ;)

-L

On 4/27/12 6:06 PM, Eric Shepherd wrote:

> Don't we already do that though?
>