← Back to team overview

nunit-dev team mailing list archive

Re: Blueprint format

 

Hi Olof,

I've been thinking about some critical blueprints I have to
write, but now I think I should put that aside and do a 
few rather easy ones, so we can discuss format. :-)

Feel free to create any you are interested in yourself - it
doesn't take any special launchpad authority and I just
made sure you could write under :dev:specs in the wiki.

Charlie
 

> -----Original Message-----
> From: Olof Bjarnason [mailto:olof.bjarnason@xxxxxxxxx] 
> Sent: Monday, August 17, 2009 10:58 AM
> To: Charlie Poole
> Cc: Andreas Schlapsi; nunit-dev@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Nunit-dev] Blueprint format
> 
> 2009/8/17 Charlie Poole <charlie@xxxxxxxxx>:
> > Hi Olof,
> >
> >> Sound OK to me, although I find the separation of "design"
> >> and "implementation" somewhat strange.. To me they are the 
> same thing.
> >
> > Maybe the words are wrong.
> >
> >> Here's an attempt..
> >>
> >> Summary
> >> Rationale
> >> Usage examples
> >
> > User stories?
> 
> Wording is so hard! :)
> 
> I meant what you seem to be meaning with "Design" - the public API.
> 
> Even more to the point: I meant examples of the usage of the 
> proposed new feature, as in how it would look to the end 
> user, in code.
> 
> >
> >> Design suggestions
> >
> > If this is a specification, then suggestions doesn't seem 
> to make much 
> > sense. Maybe you are thinking that the design may be implemented by 
> > somebody other than the author of the blueprint, and you 
> don't want to 
> > lock them down too much. In that case, I would say only put in what 
> > needs to be specified and leave out everything else.
> 
> Yes suggestions was meant as "hints on implementation". But 
> I'm not quite fond of this as it suggests things that ought 
> to be left for later (after writing the first test!).
> 
> >
> >> Unresolved issues
> >
> > This could be a transient heading untill things are 
> actually resolved.
> >
> > I'm still not sure about implementation - maybe we need it for some 
> > specs. For example, we may decide to release a feature in 
> stages and 
> > we would want that as part of an implementation plan. Certainly, we 
> > don't need a section that tells us how to code it.
> 
> I think I like your later suggestion on this thread - wait 
> with anything "template:ish" and in general, be liberal.
> 
> With that said - I wouldn't mind if the "start here templete" 
> would adhere to the development style of 90% of the NUnit 
> developers (I
> guess): TDD. So instead if talking of details, just explain 
> via examples.
> 
> Examples + rationale are the only important stuff I think ..
> 
> >
> > Charlie
> >>
> >> >
> >> > Andreas
> >> >
> >> > --
> >> > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> >> > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
> >> >
> >> > _______________________________________________
> >> > Mailing list: https://launchpad.net/~nunit-dev Post to     :
> >> > nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
> >> > https://launchpad.net/~nunit-dev More help   :
> >> > https://help.launchpad.net/ListHelp
> >> >
> >>
> >>
> >>
> >> --
> >> twitter.com/olofb
> >> olofb.wordpress.com
> >> olofb.wordpress.com/tag/english
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~nunit-dev Post to     : 
> >> nunit-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe : 
> >> https://launchpad.net/~nunit-dev More help   : 
> >> https://help.launchpad.net/ListHelp
> >>
> >
> >
> >
> >
> 
> 
> 
> --
> twitter.com/olofb
> olofb.wordpress.com
> olofb.wordpress.com/tag/english
> 






Follow ups

References