Re: [DotGNU]Out of list (yeah, right) - Useless edits...

[Mason Ham]

I think that Matthew is right on us needing to be organized. I would add
further, that I think that this project needs to take the same tact that
Apache took. Have a solid small group work on the core stuff to get it
right, and then open it up to the "bigger" masses after wards. I am not
trying to be exclusionary, to the contrary, I am trying to make it so that
the most number of people can contribute, but that means that there has to
be a core something for people to work on. That being said, I would also
suggest that the best way to go at this problem is with a modified XP. It
works as follows:
1) Choose a leader of the section. This person should be very strong in
written communications. In general this person tends not to "write" as much
code, but rather make sure that the code that is being written by people is
being communicated to other "leaders". Further, they are the point of
contact for other section leaders.
2) Choose two developer leads. These are the people that will handle the
"says so" on a given topic. The reason there are two, is that if they
disagree on a given item, the Leader breaks the tie since the concept is she
is most informed about the rest of the sections.
3) Allocate a UI person to the project. This person is responsible for
images, diagrams, pretty pictures etc. all the stuff that one needs to get
other people to understand what is being build from a visual perspective.
4) Allocate an Architect. This person will be responsible for UML. I know
this is going to be touchy to some, but I really feel that UML is the best
chance we have at a "unified" view across all languages etc.
5) Allocate a writer. This person is responsible for the documentation of
the section as a whole.
6) Test writer. This is the person that puts into useable words all the
"test cases" so the coders know when they are done.

Allocate three systems that are needed. CVS, list server, FTP.
CVS and List are obvious. FTP is for the various images, and meta files that
are needed to get ideas from one to the other, but that people don't want in
CVS. There really shouldn't be that many of them, but there always are, and
"attachment" blot is bad and had to deal with in the long run.

That is it, the rest are "coders" that build stuff and/or use or ask for
help from the people above.

Then you allocate two people to any given feature. They decide on the coding
test case, based on the feature test case and then they code. This is
different from pair programming in that you aren't doing it together,
instead you make the test case together, and then code seperately different
parts of the whole feature they are working on. Finally, each is supposed to
understand what the others code is doing, before it gets "merged" back into
the main branch. Yes this means that CVS is much harder to maintain, and
that the coders have to become "cvs experts", but it also means that people
have the opportunity to review and extend the knowledge base, it isn't so
much that two heads are better than one, it is more that one head really
would like a vacation some day ;-)

Basically it comes down to a simple principle. Think, Think again, code.
Look at what was made and extend and embrace what others build while you
where building, Think, Think again, code.

Mason

PS One final thought. I am true believer in the Test cases telling you when
a feature is done. So we should take the time before "coding" to always have
a test case for what ever we are working on.

PSS I also am only trying to help. I am not saying this is the way to do it,
I am simply saying that this one way to do it. Further, it would give us
enough "structure" to know the kinds of people we are looking for in each
project. Where do we have weakness ... ie not enough coders, or to few
writers.

PSSS Can we please have people make the address@hidden be in to line
and all others be on the cc line? it will make it easier for people to
"reply to sender" then ;-)


----- Original Message -----
From: "Matthew Copeland" <address@hidden>
To: "John" <address@hidden>
Cc: "Grant Gross" <address@hidden>; "DotGnu" <address@hidden>
Sent: Thursday, July 12, 2001 7:05 PM
Subject: Re: [DotGNU]Out of list (yeah, right) - Useless edits...


> > Microsoft employs professional writers to create their press releases,
> > and according to Dame Rumour their "grassroot's support" as well. I
> > doubt Microsoft engineers can even release a white paper without the
> > approval of the press department and a nod from the copy editors. Free
> > Developers and DotGNU should do likewise by recruiting volunteer writers
> > and editors to handle press release re-writes and copy-editing
> > documentation. Ideally they would perform QA on written work for public
> > release. What do you think?
> >
>
> I couldn't agree more.  While I appreciate the work that everyone put into
> the original, if we had gone and gotten some people whos talent is doing
> exactly this, our press release would have been of a much higher quality.
> I think that now that we have all scene the kind of quality produced by a
> professional writer, we all understand the difference between the quality
> that a good writer produces and the quality that a group might produce
> where some of the people have less experience in that area.  Quality is an
> important factor to the perception of how people will see this project.
> If we can't produce quality for people to see, how are they going to trust
> us with the quality that they can't see.  The same obviously goes for FD.
> So, rather than all of us trying to dip into areas where are experience
> isn't as great or where we don't have talents, let's work on the areas
> where our talents area t, and recruit the people who have the talents we
> need.
> Just another note, this press release was premature.  It should
> have waited until we were far more organized.  Remember, part of our main
> audience is other developers.  A perceived lack of organization by outside
> developers is not going to benefit us.  Ohh well, I am not going to mince
> words about it.  I think that so far we haven't had enough organization in
> getting things done.  Rather than talk about all the things that we could
> do for dotGNU, I am going to through out the opinion that we first need to
> get organized into managable groups where each group is set to go
> investigate some topic and come back with a specification for what they
> think the best way to handle that problem.  It would cut down the clutter
> on the main list, and would get the ball rolling a little better for the
> discussion on specific topics on sublists.
>
> The sublists don't need to be perfect, but they do need to be
> there, so if the person who has the control of the lists, and the
> person/people who are supposed to be at the head of the project can get
> together and make up the lists to discuss the different important topics,
> (including archiving please) it might make things go a little more
> smoothly.  I am not tring to give the head people a hard time.  I am just
> saying that it needs to be done, and we need to stop talking about it and
> get moving.  Once those lists are created, someone can write up a basic
> template for what kind of document should be returned to the main list.
> That way we can take the document and put into CVS.  Some programmers
> aren't very good at writing press releases, but I have found that a good
> number of programmers can at least write specification documents for how
> things should work and why.  (Of course, some do it badly, but at least it
> would be a start.  Something that we could REALLY discuss.)
>
> Matthew M. Copeland
>
> p.s.  Feel free to ignore my rantings and ravings about being organized if
> you like. I just have found that in other projects, it is useful so I am
> trying to encourage it.  If you want to hit me off list for a list of
> possible development lists from what I have observed to be the important
> issues, feel free.  You can then take them and use them how you will.
>
>
>
>
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers
>