The Proposed Product

The product vision is that there should be a simple way for a contributor to define a software item, or to update or delete an item that she has previously provided.

Probably 100 times as many people will view the list as edit it. Most people who do edit the list will do so once or twice. So it should be easy to use but there is no need to be fancy.

We're thinking that we will add a button, plus a user name and password field, somewhere on the existing view form. The contributor chooses a user name and password, and goes to a page where she can fill in the fields needed in the database. When she submits (Surrender, Dorothy!) an email will be sent to me. I'll check the entry for suitability, and OK it for release. If Dorothy wants to edit the entry later, she just enters the same user name and password, and all her contributions show up for edit. We'll probably send me an email on edits but probably will not require them to be checked, Dorothy having shown herself to be trustworthy already.

We'll need a little bit of text on the page that makes it clear that a first-time contributor just enters the id and password of their choice, but beyond that it should all be straightforward. Main list page, an entry page, and an update page. Maybe it'll even turn out that we can use one page for both entry and update.

That's all we know about the product, and probably all we need to know.

Itinerary

Where shall we go from here? We think we'll start from scratch, including defining a new database for this thing to work on.

We're discussing what to do first. Chet asks whether we should replicate the existing list page as a first release. I ask what the business value of that would be. We think ... none. We already have a list page.

That does mean that there will be a large junk task later on, converting all the existing data into the database. But if we have an empty page with no records, the customer will see the value of putting the existing data back in.

Initial Stories

Here's our initial list of stories:

1. Empty List with Unchecked Entry
   
   Create a new Software page, with an empty list; link to an entry page that can add a new record; do not check password or require approval.
2. New Entry Requires Approval
   
   Email Ron about new entry; allow approval, or perhaps assume entry is OK and Ron removes if bad. (Consider a flag on the data to display or not display a given entry.)
3. Update Old Entry with Password
   
   Allow returning contributor to update old entries by providing id and password. Extension to entry page? Do we need both id and password? Would one suffice? Both, using contributor's name, might make recoveringb passwords easier.
4. Fancy Page Using CSS
   
   Make the page look like all the others.
5. Master Password
   
   Provide a master ID and password that Ron can use to edit all items.
6. Test Deployment
   
   Deploy the page early to learn what the issues are in deployment. (Is this a technical story? Maybe not: the customer would like to be able to deploy ...)
7. Full Deployment
   
   Add existing data and ship it!

Looking at these, they seem to cover the bases, thought it is clear that there will be more refinement to do. None of these seem terribly difficult. Most of them will surely involve learning.

Possible Additional Stories

• When we bring in the existing entries, what shall we use for id and password? We would like for existing ones to be edited by their owners. Here's an idea: we'll create the id from the name of the provider or author, and the password will be random and complex. When someone wants to update, we'll send them their password.
• This brings up the possibility that someone will want to change their password. That might be a story. We'll wait til lit happens, but might take it into account in the story above. Maybe we let them pick one when they write to us, and we set it. That has the sole drawback that it relies on Ron, and we know that's a bad idea ...
• Provide for a special list of "New" items. Consider highlighting newer entries. (This is now done manually, and not very reliably.)

For now, we'll ignore all of these for planning the first release.

Estimates

Looking at the existing stories, each one looks to us as if it can be done in a single session unless we are unlucky. If we were going to commit to a specific schedule we would take at least these things into account:

• Some of these stories will be harder than we think;
• When we see what we have, we will surely want to change some things;
• We will not get a session in every day: some days we just have to discuss world affairs or plan a course or something;

We have seven stories. We only have three more sessions this week, as Sue Hendrickson will not be working Friday, so Chet can't come out to play. Next week is Thanksgiving and we may only get two sessions. We have to upgrade one of my computers someday soon. The week after is the Simple Design and Testing Conference. We'll surely be traveling on Friday, and may well plan a session for the conference.

Bottom line, we think we can probably deploy in the first week of December. There is a slim chance we can deploy sooner but I think I would predict December 7th. Stuff will happen. We will, of course, keep our customer, and you, posted.