nunit-dev team mailing list archive

["Charlie Poole" <charlie@xxxxxxxxx>]

Hi André, 

> How do you expect things to work when a new feature or change 
> is being discussed? The line between "general discussion" and 
> "implementation" is sometimes blurry (as in "everything can 
> be done as it would require too much work, so let's see what 
> we can actually do"), but neither mailing list includes both 
> parts of the discussion...  
> So what do you propose?
> Parallel discussions? Deciding on a case-by-case basis using 
> good sense?

Almost nothing is too complicated to accept - that's why we
have a backlog of over 100 feature requests on Sourceforge. :-)

I'm hoping we can stop just accepting everything and adding it
to a list we'll work on when we can. Launchpad gives us a way
of sheperding an implementation proposal through (blueprints)
but not so much of a way for deciding on value - which leaves
either discussion lists or this new experiment with ideatorrent.

I grant it's almost impossible to leave implementability out of
a discussion of a feature with users - and also impossible to
avoid discussing value when prioritizing effort internally. 
Still, I think it's fairly easy to distinguish in practice,
at least most of the time.

For example, these are user discussions:

1. Is it better for test cases to be sorted or just listed as
NUnit gets them? What are the pros and cons for the user?

2. Should nunit allow you to designate a name to be used for
a test fixture - other than it's class name, that is.

3. What icons would you like to see for different test results?

These are developer discussions:

1. Are we willing to use some heuristic re-ordering to make 
attributes come out in lexical even if .NET doesn't do that.

2. Should the specified test name be carried in a separate
field or just overwrite the existing name fields.

3. What size must the icons be and what's the best format.

> Or maybe I'm just didn't understand you correctly, and/or am 
> needlessly complicating things :)

I probably started it by trying to write a general statement.
It's really a lot easier to decide on a case by case basis.
 
> Also, I'd make "Proposals for changes and discussions of 
> proposed changes, including the implementation of new 
> features." a bit more explicit, as that can confuse some 
> people who don't immediately see the difference between 
> "changes" and "new features"... Especially since you say "New 
> feature ideas should first be proposed and discussed" elsewhere.
> I can't, however, currently think of a better wording - maybe 
> something along the lines of "Discussing changes to existing 
> NUnit features" and "Discussing implementation details of new 
> features"? But even so the line between "user-visible 
> changes" and "internal changes" is blurry...

I'll work on it.

Charlie
> 
> Thanks!
> 
> - André
> 
> Charlie Poole wrote:
> > Hi All
> >
> > So my *second* post to this list was not about any of the topics 
> > below. :-)
> >
> > Please add
> >
> > * Discussions of our own practices and how to do things like
> >   setting up a repository, merging changes, etc.
> >
> > to the things we talk about.
> >
> > Charlie
> >
> >   
> >> -----Original Message-----
> >> From: nunit-dev-bounces+charlie=nunit.com@xxxxxxxxxxxxxxxxxxx
> >> [mailto:nunit-dev-bounces+charlie=nunit.com@xxxxxxxxxxxxxxxxxx
> >> t] On Behalf Of Charlie Poole
> >> Sent: Tuesday, July 07, 2009 2:29 PM
> >> To: nunit-dev@xxxxxxxxxxxxxxxxxxx
> >> Subject: [Nunit-dev] Purpose of this List
> >>
> >> Hi All,
> >>
> >> Welcome to the NUnit Developers list. I thought I'd start 
> out with a 
> >> note describing the purpose I imagined for this list as 
> well as the 
> >> team itself. Since our move to Launchpad is a work in 
> progress, a lot 
> >> of it is open to discussion, so feel free to give some feedback at 
> >> this point. Once we have a discussion - or if there is none - I'll 
> >> create a shorter statement of purpose to be sent to any new 
> >> enrollees.
> >>
> >> BACKGROUND
> >> There have been several iterations of change in the way the NUnit 
> >> project communicates. Most recently, I set up nunit-discuss as a 
> >> place for everything. It has covered user help, best practices, 
> >> suggested features, internal project organization, nunit 
> design and 
> >> implementation issues and even submittal and review of patches.
> >>
> >> Lately, however, I've seen us spend what seems to me to be 
> too much 
> >> time focused on technical developer discussion - how to implement 
> >> something - rather than on the value of the feature under 
> discussion 
> >> - whether we want to implement it.
> >> I wouldn't mind the dev-oriented discussion if it didn't drive out 
> >> the user-oriented bit, but it seems that it does.
> >> So, that's one reason for a separate list.
> >>
> >> Another reason is that we are re-structuring NUnit from a single 
> >> monolithic project to a set of projects. Currently, we have a 
> >> framework project and others (the gui for example) will 
> get set up as 
> >> soon as that one is under way. I hope that multiple projects will 
> >> lead to an increase in participation, which will lead to 
> an increase 
> >> in dev-oriented discussion, another reason for a separate list.
> >>
> >> But the biggest reason to have nunit-dev is that it is the 
> mail list 
> >> or the nunit-xtp "superproject" - Launchpad calls it a 
> project group 
> >> - which I see as the public interface to nunit 
> development. It should 
> >> work no matter how we decide to structure our projects.
> >>
> >> With that said, here is my proposed statement of purpose...
> >>
> >> PURPOSE
> >>
> >>     
> >>>>>>>>> This would be posted as our purpose
> >>>>>>>>>                   
> >> This list is used for discussions about the development of 
> the NUnit 
> >> Extended Testing Platform and its component projects on Launchpad.
> >>
> >> Topics that are appropriate for discussion here include:
> >>
> >> * The design of NUnit, it's component projects and
> >>   the interfaces between them.
> >> * Assignment and status of work on NUnit.
> >> * Scheduling of milestones and releases.
> >> * Discussion of reported bugs when the correct behavior
> >>   is not clear.
> >> * Proposals for changes and discussions of proposed changes,
> >>   including the implementation of new features.
> >> * Coordinating the review of patches, at least until we
> >>   define some other mechanism.
> >> * Proposals for new projects under the NUnit umbrella.
> >> * Discussions of responsibility between the different
> >>   component projects.
> >>
> >> Some topics belong elsewhere:
> >>
> >> * User support questions are handled on the nunit-discuss list
> >>   or - for some projects - the Launchpad Answers system.
> >> * New feature ideas should first be proposed and discussed in
> >>   a way that gives NUnit users an opportunity to provide feedback.
> >>   (This is currently done on the nunit-discuss list or the
> >>   NUnit ideatorrent on Sourceforge.)
> >> * Bugs should be reported using the bug-tracking mechanism
> >>   set up for each project.
> >>     
> >>>>>>>>>>>   End of Purpose Posting
> >>>>>>>>>>>                       
> >> Like I said, this is a draft, so let me know whether you think it 
> >> covers what needs to be said.
> >>
> >> Charlie
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >>
> >>     
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >   
>