At 4:56 AM +0200 2006-08-31, Bretton Vine wrote: > So far my experience has been wonderful with the product, good and bad with > the documentation, and rather difficult in terms of user-error, namely mine.
I am of the opinion that all software sucks, but some sucks less than others. IMO, Mailman sucks less than any other MLM I've seen. Of course, amongst most open-source projects, documentation is a serious weak spot. Those who are developers write code, not documentation. And if they do write documentation, you frequently wish that they hadn't. Those who are operational-types (like me) don't write code, and usually don't write documentation, and if they do write documentation you frequently wish that they hadn't. The good documentation writers rarely seem to cross paths with any open source project I've seen. It's a known serious weak spot within the Mailman project, and we'd love to be able to resolve this issue, but that means we need to get some people onboard that are good at writing documentation. Any suggestions you may have in this area would be gratefully accepted. > No offence intended, but this is a rather closed-off point of view. It's > completely valid yes, but leaves no room for organic growth. A view of "we > have enough users, we do this for our own reasons, we know we can improve > this and that but there's no urgency" actually shrinks a community in the > end. I can't say where things will end up. I don't think I can even make much of a guess. I can tell you that we're getting a large enough influx of users that it is difficult for us to keep up without doing anything more to actively draw in more users. In that kind of high-growth environment, it's hard to justify doing anything that would actively draw in more users and would likely hamper other development efforts that we consider to be more important than maximum growth of the userbase in the shortest possible time. My preference would be to have a more sustainable growth pattern over a longer period of time, based on a higher quality product that we've been able to develop and field, then let the growth take care of itself. But that's just my personal view, and is not necessarily shared by anyone else. > I'm not saying there's an obligation to use or prove your software (and > time/effort interacting with the user base) just that any project can become > bigger than the sum of its parts and developers should be aware of that. I think that the developers are well aware of this issue, especially since multiple other groups have taken the Mailman code and made unapproved changes to it, and then fielded that to their users -- but without providing adequate support for their modified versions and thus leaving us holding the bag they created. >> That's fine, too. If they want to go off by themselves and learn their >> lessons the hard way, then that at least gets them out of our hair. > > Doesn't seem quite efficient to have people duplicating labour for no reason > other than stubbornness. Sometimes you can't stop them, no matter what you do. IMO, when you discover that the kind of situation you've got with a particular person, then the best thing to do is to recommend that they go ahead and do whatever they want on their own systems and to report back to you regarding their success. Otherwise, you're mud wrestling with a pig, which only gets you dirty and sweaty and annoys the pig. > However my point is that Mailman will still be used commercially. True. Like it or not, there's nothing we can do to stop them. > Which > creates expectations. Also true. > You can't manage the expectations of others so it's a > difficult road to travel. Indeed. We do the best we can through what documentation is available (including the FAQ), but there's little we can do beyond that. > I understand. But look at it from a point-of-view of say a prior majordomo > installation where the safe defaults are different defaults. Look at it from > the point-of-view of someone who knows the prior defaults and may be > confused by the change. Yes the new defaults are safe, but why? > (obvious answer: changing environment and needs) Majordomo is different from Mailman, and I would not be surprised if certain features were present in one package and not in the other, or if certain defaults were set one way in one package and the opposite way in the other. But if people don't understand that different software is frequently different, I'm not sure that there's much I can do to help them, and I'm not sure that there's much that anyone else can do to help them, either. >> For the lowest common denominator? None. Even the simplest possible >> web interface would be too complex for them. > > Boy, that's harsh. Do you want a complete and total moron to have his finger on the nuclear button, and capable of blowing up the entire planet many times over? Oh, waitaminnit, we already have that situation.... > I've knocked out our system quite a few times (by accident or oversight) and > yes there's often hell to pay and some sleepless nights -- but we've yet to > find a user who takes the system down because they have a web-interface or > email-interface to the system so they can manage their own list. The number of things that a list moderator or list admin can do through the web are limited, and the danger is reduced. But if/when we make all site administration functions available through the web, the danger will be quite a bit higher. Even list admins can subscribe a bunch of other addresses to their lists, and create loops with their subscriptions. It only takes one loop that causes every message coming in to the list to be duplicated and then re-sent back to the same list (and duplicated again, ad nauseum), to bring down the whole system. If you've got a large system (e.g., something that can generate millions of mail messages per day), it's easy enough to make a mistake that could take down a lot of other systems around the world and not just your own. These are powerful tools we're talking about here, and it's easy to do things to wind up accidentally shooting yourself in the foot -- or maybe accidentally shooting your neighbor in the head. With powerful tools, you also need powerful safeguards. > In alternate reality one, the safe defaults are automatically decided for > the user. In alternate reality two they are suggested but the user has to > enable them. Which reality informs the user more? Right, but precisely who is our "user", or perhaps I should say "customer"? I submit that *our* customer is the site admin, and this is precisely the kind of thing we offer to them. The customer(s) of the site admin would be the list admin(s), and the customer(s) of the list admin(s) would be the list moderator(s) and the list recipient(s). So, it's up to the site admin(s) to look through the defaults we've provided to them and decide which ones they want to change for their customers, and it's up to the list admin(s) to look through the defaults they're given by the site admin(s) and decide which ones that they want to change for their customers. I submit we've done our job for our customers, and it's up to them to do their job for their customers, and so on. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp