>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 [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
