[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Project scope was Re: Thoughts on Voiding Invoices

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
Ledger-smb-devel mailing list