← Back to team overview

nunit-dev team mailing list archive

Re: Blueprint format

 

Hi Andreas,

First off, thanks for stepping up to this task. I have been
thinking we need some guidance for people creating blueprints
but haven't really had the time to do it. So thank you. 

> I started to work on the blueprint for the console runner. 
> Since we don't have any blueprints in our wiki by now I 
> thought about the format we could use and I started to look 
> at other projects on Launchpad.
> 
> The one I liked most was the format of the Ubuntu project. 
> All of their blueprints have sections called Summary, 
> Rationale, Use Cases, Design, Implementation, and Unresolved 
> Issues. Maybe we won't need all of these sections, but I like 
> the idea to structure the blueprints in a consistent way.
> 
> What do you think of this idea? What would be our sections?

I notice that the Ubuntu project isn't rigid about this. Some
blueprints have added headings like "Test Plan" while others
don't have all the details worked out - for example, see
https://wiki.ubuntu.com/QATeam/Specs/MobileAutomatedTests

That's OK - we don't want to be rigid either. IMO, we don't
need the degree of pre-planning that goes into Ubuntu work.
After all it's just a bit larger than we are. :-)

That said, go ahead and use the headings you like. I'll try
to do it myself on a few blueprints and we can standardize
based on some actual experience.

Here are some implementation details:

Let's create these in a :dev:specs namespace on the wiki.
If you send me a template as a text file I can make sure
that it's used for new pages in that namespace. Putting
it under dev makes it writable only by those I put in
the dev group - others can use the talk page. Does that
make sense, or am I being too cautious granting access?

Don't get any more detailed about implementation than
you need to be. I'd just indicate what areas are
affected and the details of any public APIs.

Remember that there are two levels of design for us.
The first is really about the API design. The second
is about how we implement it. (Maybe that's what
design versus implementation means) For example, in
talking about adding a way to order tests, we might
want to
 * Discuss the rationale for doing it (Rationale)
 * Specify exactly how a user will indicate order (Design?)
 * Describe what needs to be changed to implement it (Implementation?)

Charlie






Follow ups

References