nunit-dev team mailing list archive

[Andreas Schlapsi <a.schlapsi@xxxxxx>]

Hi Charlie,

> 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 think it's important to provide some guidance for those who are not
accustomed to write blueprints for Open Source projects. I have the same
problem so I had to figure out how to start.

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

Just a little bit. :-)

I agree with that we don't want to be rigid about the structure.


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

I think it makes sense.

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

The implementation section is the one I didn't like. I already have
experience with too detailed specifications as developer and I didn't
like it. But some high-level implementation hints could be useful.

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

But not too detailed.


Andreas

> 
> Charlie
> 
> 
>