So what's the best way to go about this sort of thing? One of the biggest
handicaps is the absence of any guidance in the form of requirements or
architecture documentation. There's no context for making decisions on what
sort of changes are worthwhile. Can we agree on some way to work this?
I've seen in other cases long architecture discussions on mailing lists
have the effective cause of causing work to not happen. I'm not saying
that discussions are necessarily bad, but in the end, someone has to
be in charge and say, "yes" or "no" ... and for open source projects
who is in charge is sometimes kinda murky. For example, we could say
that up until recently, I was in charge in nmh .... but was I? I
basically let anyone commit anything that they wanted to. Now Jon
is probably in charge. As far as I'm concerned, what happens next
in terms of Great Revamping is up to him.
To give people an example of discussions that stop work ... I'll throw
out a perennial item on people's nmh Wish List: IMAP support. Once
people have agreed on what exactly that _means_ (that discussion always
seems to take a ridiculous amount of time), there is always a vocal
minority which stands up and says, "Well, if nmh were to support IMAP,
if I was using IMAP I wouldn't be able to use this one tiny feature of
nmh that even Jerry Peek hasn't heard of, but is absolutely essential
to my handling of email". Okay, this is perhaps an exaggeration, but
not much of one. Sitting on the sidelines, it always seems to me that
these discussions have the net effect of preventing IMAP work from
happening. Perhaps no IMAP work would have took place even if everyone
had said, "Sounds great, go for it!", but I know from personal
experience that it's hard to get excited about a volunteer, open-source
project when people are telling you that your idea is stupid.
So, I guess my general point is: I think that anyone who wants to do
_any_ work on nmh, should just Do it and commit it to the tree. The
only exceptions I can think of are ones that affect portability and
backwards compatibility (obviously "backwards compatibility" is a
judgement call, and someone needs to be in charge for that one).
Do we need an architecture document? Well, I guess if someone wants
to write one, that would be great. But documentation has always been
the weak side of open-source projects.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers