Requirements Summary

[David MacQuigg]

I've started a Requirements document (See requirements.txt in our
Files area.) I've also uploaded this to a new group PyKata, in case
the Files area in PyWhip becomes inaccessible, as it was for two
weeks. The PyKata group will eventually be our place for discussions
among users, but for now just use it as backup storage.

Requirements are a concise statement of *what* we want, not *how* it
is to be done. Sometimes it is difficult to separate requirements
from implementation detail, especially if we give examples and mockups
of specific implementations. We will work closely with our developer,
so he/she can easily say "I can't do exactly that, but here is
something at least as good."

Working early on a clear set of requirements has two benefits.
1) It brings out the best ideas from everyone involved, and avoids any
misunderstanding of where we are headed.
2) It allows our developer to think and plan well in advance of
getting buried in code, and avoids surprises when we discover things
don't work as expected.

Let's focus first on the section "Student Feedback", and get that part
ready for our developer to start work. We've had a lot of good
suggestions in this group and in the student proposals, both as to
website design and on how to organize our content. Organization of
content probably deserves a separate document, so we can keep the
focus here on how the website is supposed to work, including features
needed by authors in organizing their content.

--
You received this message because you are subscribed to the Google Groups "PyWhip" group.
To post to this group, send email to pyw...@googlegroups.com.
To unsubscribe from this group, send email to pywhip+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pywhip?hl=en.

[Eliseo Ocampos]

David,

On Fri, Apr 16, 2010 at 3:31 PM, David MacQuigg <macq...@box67.com> wrote:
> I've started a Requirements document (See requirements.txt in our
> Files area.)
I've also uploaded this to a new group PyKata, in case
> the Files area in PyWhip becomes inaccessible, as it was for two
> weeks.  The PyKata group will eventually be our place for discussions
> among users, but for now just use it as backup storage.
>
> Requirements are a concise statement of *what* we want, not *how* it
> is to be done.  Sometimes it is difficult to separate requirements
> from implementation detail, especially if we give examples and mockups
> of specific implementations.  We will work closely with our developer,
> so he/she can easily say "I can't do exactly that, but here is
> something at least as good."
>
> Working early on a clear set of requirements has two benefits.
> 1) It brings out the best ideas from everyone involved, and avoids any
> misunderstanding of where we are headed.
> 2) It allows our developer to think and plan well in advance of
> getting buried in code, and avoids surprises when we discover things
> don't work as expected.
>

I find this a very valuable idea for the project, It's important to
state towards where we are heading in a colective way.

> Let's focus first on the section "Student Feedback", and get that part
> ready for our developer to start work.  We've had a lot of good
> suggestions in this group and in the student proposals, both as to
> website design and on how to organize our content.  Organization of
> content probably deserves a separate document, so we can keep the
> focus here on how the website is supposed to work, including features
> needed by authors in organizing their content.
>

I have a doubt about this (from requeriments.txt):
"Requirements labeled V1 (version 1) are needed for an essentially
complete, but minimal website. V2 will be for things with lower
priority. We will get them done if there is time."

Is this reffering to a (probable) selected GSoC proposal's cronogram?
Or do we will have another timeline/milestone?

Regards,
Eliseo.

[David MacQuigg]

Eliseo Ocampos wrote:
> I have a doubt about this (from requeriments.txt):
>> "Requirements labeled V1 (version 1) are needed for an essentially
>> complete, but minimal website. V2 will be for things with lower
>> priority. We will get them done if there is time."
>
> Is this reffering to a (probable) selected GSoC proposal's cronogram?
> Or do we will have another timeline/milestone?
>

The Requirements document is intended to be a high-level statement. The
proposals should have details such as a timeline. The intent of having
two categories of priority is to clearly separate what must be finished,
tested, debugged and polished, from what is nice, but less essential.
There is great temptation in a project like this to get the essential
features 90% done, and put off the debugging to work on new and exciting
features. This almost always leads to not finishing anything.

So at the expense of perhaps doing a little extra work, we are going to
insist that the essential features get done early, and that debugging
and polishing of these features take priority over working on the nice,
but non-essential features. I say "perhaps", because it looks to me
like the features we have been discussing are non-overlapping. For
example, the effort on polishing the teacher report page for Version 1
will not be wasted because we replace it with something better in Version 2.

We can minimize any debug/rework effort by asking teachers and others on
this list help with planning and beta testing. I will make sure that
effort is organized, so our developer will have a clear understanding of
the high-level requirements, and rapid feedback as soon as anything is
ready for testing.