Richard Wackerbarth writes: > > On Apr 28, 2013, at 6:54 PM, Stephen J. Turnbull <step...@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 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
