[Mailman-Developers] Architecture for extra profile info

[Stephen J. Turnbull]

Richard Wackerbarth writes:
 > 
 > On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
 > > The rest of your post is just a reiteration of your religious
 > > belief that generic is good.
 > 
 > Call it "religion" if you wish. It is based on DECADES of
 > experience,

So are most religions, but for some reason they all have exceptions
where the Power chooses not to perform miracles.

 > many of which involved reworking existing code to
 > handle some changed conditions.

Of course you do.  Anybody with five years of experience has run into
that.  But with decades of experience, surely you've also run into
projects that never saw the light of day because the implementers
overengineered Grand Designs which didn't address user requirements.

 > Where is your design to handle the delegation of (restricted)
 > permissions to alter list settings, create new lists, add
 > moderators or administrators, etc.?

Mailman 2.1.  I've seen no real reason to suppose we need more.  What
people repeatedly request on Mailman channels (in my, eminently
fallible, recollection) is more *power* for existing administrator
roles (viewing logs), more power for the user role (searching
archives), and more intuitive UIs for both.  Barry's design for
Mailman 3 addresses those needs by making it a heck of a lot easier
to experiment with additional UIs.

An example of a use case I don't like is the "Like" buttons (or
something like that) the HyperKitty guys are putting in.  Nobody has
requested them on Mailman channels that I can recall.  But social
networks are booming, and any visit to YouTube will provide evidence
that people do use those "Like" buttons, and comment on them.  I have
no ground to stand on there.  I'm sure those buttons will be
appreciated and used by lots of subscribers.  That use case is valid,
whatever my personal feeling is.

But I've never seen (IMEFR) a request for more flexibility in
constructing an administrative organization for a Mailman site.

 > I am, at least, proposing a framework which would be able to
 > address these issues.

My point is, "Don't tell me about theoretical issues.  What use cases
are you addressing?"  If users aren't going to use your framework,
there's no point in building it.

 > This sounds as if you are using the "But you haven't actually built
 > the entire system, therefore I can dismiss anything that you
 > propose as a design concept" excuse to dismiss any ideas that are
 > "Not Invented Here"

You're not listened if that's what it sounds like to you.  I haven't
once asked you for running code.  I've asked you for examples of what
Real Users[tm] might want to run the proposed code for.

If you want to build it with your own resources, I have no problem
with that.  If you want me to help, or if you want me to support your
design to other developers (including GSoC interns), I need to know
what it's for, besides addressing issues that I do perceive in
software engineering theory, but not in Mailman practice.

Steve