[Mailman-Users] Diagnosing command failures

[Barry S. Finkel]

On 1/22/2015 10:10 AM, Gary Merrill wrote:
 > Again, thanks to all of you for your responses.  There are a number 
of thorny issues in attempting to "fix" (or at least address) what is 
"wrong" here.  The original conceptual model of something like Mailman 
isn't quite right for the situation being faced today in the types of 
capabilities and support offered to the "general public".  This doesn't 
mean that that model was wrong, but that's it's not a thoroughly good 
fit for a certain service/support/marketing model employed by others. 
Making things "fit" better is a daunting task because of the numbers and 
types of players involved, and their varied goals and constraints.  Hey, 
before I retired, I spent about 13 years developing knowledge 
representations and software (server and user) for multiple disparate 
medical coding schemes for the purposes of drug discovery and adverse 
event detection.  I know the kinds of problems you guys are facing -- 
although you should be somewhat grateful that you aren't dealing with 
the FDA, insurance
 >    companies, gigantic healthcare organizations, the CDC, and 
multiple pharma companies. :-)    "Don't hold your breath" is a 
perfectly apt comment.
 >
 > The hosting services companies may want to provide certain services 
(or at least their developers and support staffs may).  They (meaning 
the their developers and support organization) may in fact care, but 
they may be severely constrained in what they can do within the economic 
model of the company and how effectively they can fight their marketing 
organization.  The issues here often aren't technical, but economic and 
political (in the sense of company politics).  Sometimes the good guys 
win, and a lot of times they don't.  And to some degree you get what you 
pay for (if you're lucky and deal with a reputable provider).  I'm quite 
happy with the service and support that Webhostingpad has provided me (I 
have two sites hosted by them).
 >
 > Prior to running the Mailman list for this community band, I had -- 
for a year -- been running a phpBB bulletin board.  Of course this is 
quite different from Mailman, is more feature-rich, employs a completely 
different conceptual model and architecture, and required that I install 
and configure it myself.  That gave me a lot more control over it than I 
have over my Mailman lists that are available through Cpanel.  It was a 
noble experiment that failed.  While the majority of the band really 
liked the idea and functionality of forums, there was a contingent that 
was highly resistant to using that approach.  (These were not always, or 
even generally, the elder members, but somewhat oddly tend to be in the 
45-55-ish age group.)  They didn't like having to go to the site ... 
they didn't like having to employ a password to access it ... but they 
wanted to be sure that everything was secure and not visible to 
outsiders ... the primary people who in fact needed to make postings to 
the for
 >   um on a regular basis "couldn't remember" to do so, etc. 
Basically, it was something that a contingent of the organization wasn't 
familiar with and just didn't want to learn about -- whatever the 
advantages were.  It gave me a lot of flexibility and control because 
virtually everything concerning its administration was in "my own 
space".  As in the case with Mailman, I avoided any patches, custom 
code, or addition of anything other than the base modules and some 
images.  I had to abandon it because as a communication mechanism, it 
just wasn't working for this group of people.  No amount of education or 
support would solve the problem.
 >
 > I then recalled the experience I'd had with the listservs used by the 
National Library of Medicine and thought:  That should do the trick for 
this group.  Their model of online communication is email.  It's simple. 
  Of course, 80% of my organization can't distinguish between a 
privately held and maintained mailing list of contacts and a mailing 
list managed by something like Mailman -- but it's working out nicely 
and they're learning the few important fundamentals over time.  By far, 
most of them have never changed their default password (everyone 
originally was batch-subscribed) or even used their password or felt the 
need to.  Many of them have probably forgotten that they even have a 
password.
 >
 >>From my point of view, what would be ideal in managing a Mailman list 
would be to have all the relevant data for the list in "my space", and 
accessible to me so that on the rare occasions when things don't work I 
could at least look for what is causing the problem.  Some configurable 
level of logging (again with the information kept in "my space") would 
be very helpful so that this could be turned on and off as necessary. 
Perhaps administrator-configurable/editable error messages would be nice 
as well -- and ones not requiring modifying code or central files 
governing the entire Mailman instance.
 >
 > That is, some enhanced degree of "local list control" would be very 
helpful.  Currently this seems to be supported only through the ability 
to edit "public" HTML and text files (of which there are few) -- so 
someone has recognized the utility of local list control, but it's just 
never been taken very far.  This is all to say that I think much would 
be gained by moving the perspective of "the administrator" from a global 
perspective to a more list-local perspective in many instances.  Perhaps 
the upcoming release will include such things; perhaps not.  I don't 
know your architecture or your constraints, and so I'm not going to 
start pitching such ideas at you in the form of change requests.
 >
 > Mailman is currently quite nicely satisfying the needs I have, and I 
look forward to the next release.
 >
 > _______________
 >
 > Gary H. Merrill
 > Chatham Design Consultants
 > +1 919.271.7259


One quick comment on Mailman support - When I was managing a Mailman
installation on Ubuntu, I was told that I had to install a package.
I looked at the Ubuntu package and compared the source therein with
the SourceForge source.  There were many changes, and I could not
determine what they all were.  My boss told me that we could install
the Ubuntu package and then get a support contract with Debian/Ubuntu.
I told him that I was more comfortable with the SourceForge source
and the support I got from this list.  He allowed me to build a Mailman
package from the SourceForge source, and that is what I did.
I never installed the Debian/Ubuntu Mailman package, so I never had to
talk to the Debian/Ubuntu Mailman support staff.

--Barry Finkel