communication and planning of work (was Re: [DotGNU]RFC : [Proposals]ILAutoStubber Proposal)

[James Michael DuPont]

It is more important to communicate at this point in the project 
than to be a lone hacker. 
There are more people who would help if they had a clean understanding
of where they can fit in. 

If we dont present a clear set of rules that will allow for people to
contribute, to propose ideas, to get comments on them, then the project
will lose contributors.

Eventually you will be alone in your hacker stardom, producing lots of
code, but seeing people drift off towards projects that provide a
better framework for group achivement.

Communication of plans, tasks and problems is the key to this.
Commitment to tasks is also important, even if my commitment is not
fixed on a delivery date most of the time, my name is against it. If
you need it now, tell me and I will put more energy into it. If you
want to do it, then take it over.

I find that these basic problems are what are plaguing dotgnu. 
My proposal is the creating of TaskPackets.
Each Task is self contained, documented, approved. 

I see the DotGnu project as a large waster of potential in terms of
badly organized group effort.

Every person is a potential helper, or a pontential leaver.
Just look at the tunes project, they (water) just scare people off in a
big way, many potential contributers are just told to go to hell.

If you communicate your tasks, problems, and plans, you will get more
help. If you lay out a list of things that people can do, they will be
more likly to help. And it wont be all dependent on one person.

--- Rhys Weatherley <address@hidden> wrote:
> On Thursday 06 March 2003 05:48 pm, James Michael DuPont wrote:
> 
> > If you permit, then I would start by creating a Fleshed out
> > specification of the problem, like this :
> > http://wiki.dotgnu.org/TaskFoafDotGnu
> 
> It's not a question as to whether I will "permit" it or not.  The
> usual rule 
> applies: "just do it".  If it's useful to DotGNU, then we'll find a
> home for 
> it once it is done, or once it starts to show some promise.  The
> old-style 
> "propose first and ask for permission" just doesn't work.

Hmm... I think that we should have more proposals, 
even if we just do them afterwards, or not!

The proposal list is full of people proposing things, I wonder if they
ever got a response at all? Think about that. 

The problem is often the race conditions that happen. This is the
problem with the SwigSharp for example, 
there are three contenders for the SwigC# bindings.  And instead
of us planning some type of synergy, the binge project is going in the
other direction. :(

Currently, I have now gotten permission to commit the swigsharp to cvs,
and the testing with pnet is coming along well. 
This will be a real place to impress.

http://swig.cs.uchicago.edu/cgi-bin/wiki.pl?SwigSharp

This is kind of silly. 
It is not a race here. I think we could work together with a little
visibility and cooperation. This is missing in DotGNU at this moment
and that I why I am putting my effort into the task list on the wiki.



> Personally, I think you are trying to do too many things at once. 
> You should 
> pick something simple (e.g. EulerSharp), and get that working.  And
> then move 
> onto slightly more complex things (e.g. Gtk#, MathNet), and so on.

Yes, you are right, but that does not mean i cannt lay out a 2 year
plan. 

Right now I have some free time, and this can change quickly when my
new job starts. I have lots of open connections, but that does not mean
that I will close them soon.

That is basically what you see there. I ask you and others to review,
to comment and help prioritize. That way we can all see what we are
working on, and help out if need. 

When newbies come in, then can look at my task list and take some off,
If they are all prepared, documented and ready to run, it will be easy
for someone to pick up on them.

my priorities right now

Euler sharp works, but I am more interested in Mercury and Prolog,
MRLC has been porting the introspector logic to prolog, and I want to
try that out on Mercury.

Gtk# is on hold untill I restart my win32 gtk cross compiler efforts.
MathNet would be interesting... 
Also Swig will be important  for the Redland Port and the VCG wrapping
that are high on my personal task list.
 
> Very few people can keep as much state in their head as I can, and
> even I can 
> get overwhelmed sometimes.  

>Start small, and work from there.  Keep
> the grand 
> plans for later.  

yes, your right. Grand Plans are that, plans. Each step is a small step
in that direction.

> Also, the smaller it is, the more likely it is that
> I'll 
> apply the patch because I can actually understand what is going on.

Ok, well in terms of patches, that i reall true. I will be trying to
keep the patches as small as possible right now. 

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/