Re: Project scope was Re: Thoughts on Voiding Invoices

["Chris Travers" <..hidden..>]

Hi David;

There are inherent conflicts between a number of important priorities including:

1)  Some sort of plan for the future
2)  Encouraging people to contribute in ways that solve their own
immediate problems
3)  Adapting to changing needs.

I think that in our case, agile methods are better than overly planned
methods simply becuase it allows us to accept more sponsored
development and so forth.

Also, I think that a lot of SL spinoffs have run into the trap of
closed-ended planning.  I.e. now that this one problem is fixed, our
job is complete and the project dies.  I think this is something that
is important to avoid by having many open-ended sub-projects.  But I
understand that we are getting to the point where some sort of
structure is necessary and I support your request for more structure.

Rather than a formal roadmap, am going to suggest we make and maintain
the following documents:

1)  A statement of scope and mission (i.e. what we want LedgerSMB to
be in the long-run)

2)  A pseudo road-map with the following sections:
 a)  A list of features we agree will definitely be in the next release.
 b)  A list of high-priority open issues.
 c)  A list of deferred open issues (including high-priority ones
that depend on other work).

Any feedback on this proposal?

Best Wishes,
Chris Travers

On 9/25/06, David Tangye <..hidden..> wrote:
> That's the right track for sure.
>
> One point...
>
> On Mon, 2006-09-25 at 10:01 -0400, Christopher Murtagh wrote:
> > Project Scope where we all submit our
> > ideas/plans on direction for LedgerSMB and after a brief discussion we
> > come to a consensus?
>
> I would not worry about needing a brief discussion, or consensus.
>
> 1. At  any time soon, set the Scope and a Project Roadmap that gives
> possibilities for extending the scope over time
>
> 2. By all means get on and develop/code to that scope.
>
> 3. Let that discussion continue to range over time, and in fact welcome
> it. That is the main difference between a closed project with open
> source and a truly open project.
>
> 4. Make changes to the Roadmap over time as consensus on new priorities
> for functionality/changes to Scope emerge. The Roadmap is simply a
> statement of approximate Scopes (limits of functionality) optionally
> over approximate timeframes else implied 'somewhere in the future,
> possibly in this order' timeframes.
>
> At this stage I might keep the future stuff generalised enough that you
> dont get too distracted from development to have to answer nit-picking
> arguments about what exactly is further down the road in the map. The
> idea is to obtain the happy medium between 'hacking code to no plan' and
> 'analysis paralysis'.
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel