Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 18, 2010, at 01:46 PM, Stephen J. Turnbull wrote:

>Barry Warsaw writes:
>
> > It's an interesting idea, but I'm not quite sure how a webserver pipeline
> > would work.  The way the list server pipeline works now is by treating
> > messages as jobs that flow through the system.  A web request is kind of a
> > different beast.
>
>Why?  Abstractly, both web requests and mail messages are packages of
>data divided into metadata and payload.  You line up a sequence of
>Handlers, each one looks at the metadata and decides whether it wants
>a crack at the package or not.  If no, back to the pipeline.  If yes,
>it may process metadata or payload (possibly modifying them), then
>decide to (a) do something final (reject/discard it or send something
>back out to the outside world), or (b) punt it back to the pipeline
>for further processing.

The primary difference is that with email jobs, we can handle the
asynchronously and there's little demand on handling them quickly.  Web
requests are synchronous and must be handle immediately, or the browser will
time out.

It's certainly possible to turn a web request into an asynchronous job, but
it's much more complicated, and we don't often have the same access to the
underlying jobs.  With the email pipeline the MTA hands us a message and that
(plus an accompanying metadata dictionary) *is* the job.  Usually with a web
request we don't have quite the same thing, even in a WSGI environment.

>You can also keep state across requests.  If it's request-specific the
>nature of HTTP and email both require cookies (aka one-time keys).
>So, what's so different?

I'm not sure I follow about email requiring cookies.

>It seems to me that it might also make communication between the
>webserver and the mail server(s) easier to organize (eg, when the user
>sends email to list-subcribe, then confirms by clicking on the web URL
>in the response) if these "jobs" had a unified format.

I don't quite see how that follows.

>It's possible that having a thousand handlers all looking at
>everything would be horribly inefficient, then you could divide things
>up into subpipelines (in the Linux kernel firewall they're called
>chains), with master Handlers in the toplevel pipeline dispatching to
>lower level subpipelines.
>
>I thought that was how Mailman 3 was organized.  I know that Mailman
>2's mail pipeline has inspired a lot of my thoughts about how
>Roundup's internal implementation could be improved.  (Roundup
>"auditors" and "reactors" look a lot like Handlers.)  I guess I'd
>better go look more closely at Mailman 3.

Mailman 3 has the same basic architecture, except that the rule-checking
handlers live in a different pipeline and have a slightly different semantic
and interface.  Please do take a look!

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Barry Warsaw writes:

 > It's an interesting idea, but I'm not quite sure how a webserver pipeline
 > would work.  The way the list server pipeline works now is by treating
 > messages as jobs that flow through the system.  A web request is kind of a
 > different beast.

Why?  Abstractly, both web requests and mail messages are packages of
data divided into metadata and payload.  You line up a sequence of
Handlers, each one looks at the metadata and decides whether it wants
a crack at the package or not.  If no, back to the pipeline.  If yes,
it may process metadata or payload (possibly modifying them), then
decide to (a) do something final (reject/discard it or send something
back out to the outside world), or (b) punt it back to the pipeline
for further processing.

You can also keep state across requests.  If it's request-specific the
nature of HTTP and email both require cookies (aka one-time keys).
So, what's so different?

It seems to me that it might also make communication between the
webserver and the mail server(s) easier to organize (eg, when the user
sends email to list-subcribe, then confirms by clicking on the web URL
in the response) if these "jobs" had a unified format.

It's possible that having a thousand handlers all looking at
everything would be horribly inefficient, then you could divide things
up into subpipelines (in the Linux kernel firewall they're called
chains), with master Handlers in the toplevel pipeline dispatching to
lower level subpipelines.

I thought that was how Mailman 3 was organized.  I know that Mailman
2's mail pipeline has inspired a lot of my thoughts about how
Roundup's internal implementation could be improved.  (Roundup
"auditors" and "reactors" look a lot like Handlers.)  I guess I'd
better go look more closely at Mailman 3.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 16, 2010, at 09:44 PM, Stephen J. Turnbull wrote:

>But IMO the pipeline architecture already does that.  I haven't looked
>closely at the Mailman 3 webserver, but my understanding is that it
>gets a pipeline too.  It seems to me that once you have that (and IMHO
>that is extremely desirable just by analogy to the list processing
>pipeline, which I have written several Handlers for), the rest is
>going to be pretty CAPTCHA-specific, and quite possibly specific to
>the particular CAPTCHA implementation.

It's an interesting idea, but I'm not quite sure how a webserver pipeline
would work.  The way the list server pipeline works now is by treating
messages as jobs that flow through the system.  A web request is kind of a
different beast.

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 16, 2010, at 12:33 AM, Cristóbal Palmer wrote:

>Are you saying that no scripts/bots can automatically sign up for
>mailman lists? I get plenty of signups like "qneu45...@nanke62w.net"
>that suggest otherwise. I should take the time to log those and send
>them to you, perhaps? After my masters paper...

Only if I can send you all the bounces and unsubs I get every month on Mailman
day. :)

>Okay... now that I've put all this energy into this explanation, I'll
>admit: spam to list owners, especially of the "Dear $LISTNAME owner,
>we at $SITENAME security need you to reset your password. Please find
>instructions in the attached .zip file..." were a much bigger problem
>a couple of years ago (surprisingly even after implementing SA) until
>I decided to block .zip and several other mime types at the MTA
>level. So if y'all have no interest in doing any reCAPTCHA
>integration, I'll just spend that much more time making anti-spam
>tweaks at the MTA level, and I'll field one or two more "I'm a
>moderator and I'm dealing with a lot of spam here" tickets every now
>and then.

Two points: antispam defenses are always going to be better done in the MTA
upstream of Mailman.  We may provide some hooks to allow integration with
SA/spambayes/clam/etc. but just seeing the cpu these take up on my measly
server I do not think I want such a check running on everything teh intarwebs
can throw at your lists domain.

Second, I intend to pass -owner email through a pipeline the way posted
messages go through, so you will at least have the opportunity to do some
content and other checks on the message before they're forwarded to the
owners.

>That's another point, come to think of it: I've had plenty of time and
>experience running a couple of decently-sized mailman installs, but
>what about the many, many people who have less experience running
>mailman? The easier we make it for them to make it hard on spammers,
>the better.

Yes, we should be opinionated and make reasonable defaults so that it's easy
to install and run a working system, with good tradeoffs between usability,
functionality and security.  These are not always easy tradeoffs to make.

>A final note: are there any published user studies on mailman? I see
>your ATEC '03 and LISA '98 presentations in the ACM portal, and I see
>http://www.gnu.org/software/mailman/otherstuff.html ... but nothing
>else turns up in google scholar. Please point me to other research on
>mailman and its user base if it exists. If it doesn't, maybe I need to
>make that happen

Terri was talking at one point of contracting such research, and I think some
is being done as part of the GSoC work.  None exists that I know of.  If
you're offering, I'm sure we would love to have some additional solid
usability studies, especially focused on helping to guide Mailman 3 design.

>Thanks so much for all the work all of you do. It really is a pleasure
>and a privilege to be involved.

Thanks to you and everyone who contributes to Mailman development.  It truly
is a great community.

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Cristóbal Palmer writes:
 > On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote:
 > > 
 > > The question is "what are they protecting?"  My claim is that if
 > > you're protecting economic resources (bandwidth, accurate counts of
 > > real users) they may be more or less useful.  If it's a security issue
 > > -- including ways of harvesting email addresses that involve
 > > subscribing -- though, you're busted.
 > 
 > To my mind the main resources we're protecting are moderator time and
 > site owner time, and we're admittedly cost shifting onto subscribers
 > for lists where CAPTCHAs are enabled.

I consider that a valid tradeoff, with the breakeven point to be
determined by the moderators/list owners/site owners.

OK, I'm happy again, no crazy people here. :-)

 > But think of it this way: if what mailman does is provide a plugin
 > spot for something external to do CAPTCHA or CAPTCHA-like work, then
 > some non-CAPTCHA method could be inserted that doesn't impose user
 > load.

But IMO the pipeline architecture already does that.  I haven't looked
closely at the Mailman 3 webserver, but my understanding is that it
gets a pipeline too.  It seems to me that once you have that (and IMHO
that is extremely desirable just by analogy to the list processing
pipeline, which I have written several Handlers for), the rest is
going to be pretty CAPTCHA-specific, and quite possibly specific to
the particular CAPTCHA implementation.

It might be worth recommending a third-party implementation of a
best-of-breed (reCAPTCHA?) plugin or even providing one ourselves, but
I plan to leave that decision to Barry, as long as the documentation
for any such feature points out the limitations of the technology.

 > Also, sorry about your stolen bike. :(

Don't be.  It was a $150 bike, and the Minister of Finance in my house
approved purchase of a $670 replacement. :-)  All I really lost was a
junk lock and about $50 resale value.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Adam McGreggor]

On Wed, Jun 16, 2010 at 12:57:59AM -0400, Cristóbal Palmer wrote:
> While I'm digging around and thinking of other anti-spam tools, maybe
> it's worth digging around in here for ideas, since this seems rather
> popular with WordPress:
> http://www.bad-behavior.ioerror.us/documentation/

Another one to look at (I'm not exactly a 'fan' of bad-behavior),
is http://mollom.com/features (and http://mollom.com/benefits) -- it's
quite a popular (aiui) plugin/module for Drupal-based/powered sites to
use.

(apparently, there's a Python library available at
http://github.com/itkovian/PyMollom)

-- 
"A traitor may betray himself and do good that he does not intend"
-- J. R. R. Tolkien
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Cristóbal Palmer]

On Wed, Jun 16, 2010 at 01:03:20PM +0900, Stephen J. Turnbull wrote:
> 
> The question is "what are they protecting?"  My claim is that if
> you're protecting economic resources (bandwidth, accurate counts of
> real users) they may be more or less useful.  If it's a security issue
> -- including ways of harvesting email addresses that involve
> subscribing -- though, you're busted.

To my mind the main resources we're protecting are moderator time and
site owner time, and we're admittedly cost shifting onto subscribers
for lists where CAPTCHAs are enabled.

> Mailman should clearly not provide any CAPTCHA implementation itself,
> given your claims of rapid progress in the field.

Not my claim. Others in the literature. I can do more digging if you
don't believe me or don't have institutional access. Regardless, we're
in agreement that it should not be the job of the MLM to provide the
CAPTCHA. I'd just like a tested, approved way to plug in reCAPTCHA at
the moment. I'll do it myself without any help from y'all (after my
masters paper), but I think this would benefit the community.

>  > and that I'm insisting people use cheap locks.
> 
> No, that's not my claim.  My claim is that it is unethical to make
> weak locks available for free, without explaining to people their
> correct use.

Ahhh. Very much agree. Also, sorry about your stolen bike. :(

> The first thing I want to see, then, is documentation that CAPTCHAs
> are more effective than other methods of confusing the dumb 'bots.

http://www.sciencemag.org/cgi/content/full/321/5895/1465

Originally published in Science Express on 14 August 2008
Science 12 September 2008:
Vol. 321. no. 5895, pp. 1465 - 1468
DOI: 10.1126/science.1160379

http://recaptcha.net/faq.html

Good a place as any take it up with the authors.

But think of it this way: if what mailman does is provide a plugin
spot for something external to do CAPTCHA or CAPTCHA-like work, then
some non-CAPTCHA method could be inserted that doesn't impose user
load. For example, people could use a plugin that adds a junk form
field that is hidden by CSS, or a simple 1 + 2 math problem, or any
number of other things. The point is that we're doing the equivalent
of adding braze-ons to the seat stays of a bicycle frame: whether the
user adds a sturdy rack, a cheap one, or none at all is up to them.

While I'm digging around and thinking of other anti-spam tools, maybe
it's worth digging around in here for ideas, since this seems rather
popular with WordPress:
http://www.bad-behavior.ioerror.us/documentation/

Cheers,
-- 
Cristóbal Palmer
ibiblio.org
metalab.unc.edu
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Cristóbal Palmer]

On Tue, Jun 15, 2010 at 10:44:03PM -0400, Barry Warsaw wrote:
> 
> Given that all signups require an email validation step, and that we'll
> rate-limit that to prevent using signups as a spam vector, what additional
> protection does captcha provide?

Are you saying that no scripts/bots can automatically sign up for
mailman lists? I get plenty of signups like "qneu45...@nanke62w.net"
that suggest otherwise. I should take the time to log those and send
them to you, perhaps? After my masters paper...

Most of these numbers are educated guess numbers; if you want real,
validated numbers they'll have to wait, again, until I turn in my
masters paper. With that...

Let's say I have a large list that receives 16 signups a day, and of
those two are actually humans and not scripts. The list owner, having
had trouble with spammy signups in the past, has set the list to
require moderator approval before users can post. What are the human
costs?  We'll say that the two human signups took 40s each (80s), and
the moderator also took 40 seconds per signup (640s), for a total of
720s = 12 minutes.

Now let's assume the reCAPTCHA adds 13s[0] to real human signups and
cuts down spammy signups to 4 per day and re-run our math. The two
people now spend 106s and the moderator spends 160s, or 4.43 minutes.

Yes, we've shifted some costs to our subscribers, but they do that
once, and the moderator gets back time daily. What's more, we've
increased their burden by just over a quarter and almost divided the
moderators burden by three. And we haven't even mentioned the
increased cost to the spammer, or (in the case of reCAPTCHA) the
benefit to society the CAPTCHA solving work.

That's the real point of all this: drive up the cost to spammers as
much as possible while imposing as little burden as is reasonable on
list owners, moderators, subscribers, site admins, etc. We can't
exactly follow the metafilter model[0] here, and I think this is as
good an idea as I have seen, but I'd love for others to propose
something else that imposes less of a burden on subscribers and we
know will drive up costs to spammers over a longer-term basis.

Again, I don't even propose we turn this on by default. I would just
like to see this as a documented, tested option that can be enabled by
site admins and cleanly upgraded without extra work.

Okay... now that I've put all this energy into this explanation, I'll
admit: spam to list owners, especially of the "Dear $LISTNAME owner,
we at $SITENAME security need you to reset your password. Please find
instructions in the attached .zip file..." were a much bigger problem
a couple of years ago (surprisingly even after implementing SA) until
I decided to block .zip and several other mime types at the MTA
level. So if y'all have no interest in doing any reCAPTCHA
integration, I'll just spend that much more time making anti-spam
tweaks at the MTA level, and I'll field one or two more "I'm a
moderator and I'm dealing with a lot of spam here" tickets every now
and then.

That's another point, come to think of it: I've had plenty of time and
experience running a couple of decently-sized mailman installs, but
what about the many, many people who have less experience running
mailman? The easier we make it for them to make it hard on spammers,
the better.

A final note: are there any published user studies on mailman? I see
your ATEC '03 and LISA '98 presentations in the ACM portal, and I see
http://www.gnu.org/software/mailman/otherstuff.html ... but nothing
else turns up in google scholar. Please point me to other research on
mailman and its user base if it exists. If it doesn't, maybe I need to
make that happen

Thanks so much for all the work all of you do. It really is a pleasure
and a privilege to be involved.

Cheers,
-- 
Cristóbal Palmer
ibiblio.org
metalab.unc.edu

[0] http://www.sciencemag.org/cgi/content/full/321/5895/1465
"reCAPTCHA: Human-Based Character Recognition via Web Security Measures."
Originally published in Science Express on 14 August 2008
Science 12 September 2008:
Vol. 321. no. 5895, pp. 1465 - 1468
DOI: 10.1126/science.1160379

Quoting:

User testing on our site (http://captcha.net) showed that it took
13.51 s on average (SD = 6.37) for 1000 randomly chosen users to solve
a seven-letter conventional CAPTCHA (25th percentile was 8.28 s,
median was 12.62 s, and 75th percentile was 17.12 s), whereas it took
13.06 s on average (SD = 7.67) for a different set of 1000 randomly
chosen users (also from http://captcha.net) to solve a reCAPTCHA (25th
percentile was 5.79 s, median was 12.64 s, and 75th percentile was
18.91 s).

[1] Charge five US dollars (paypal) for an account.
___
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.pyt

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Cristóbal Palmer writes:

 > While I could in theory maintain a patch, I have a lot of machines to
 > herd, and I am unlikely to customize anything unless I must do so in
 > order to meet a requirement.

This is a straw man in the context of the Mailman pipelined
architecture and the CheeseShop.

 > While I share your distaste for bad implementations of... anything,
 > really, CAPTCHAs do not annoy me unless they are poorly implemented,
 > and they do not have to be poorly implemented.

Show me some well-implemented CAPTCHAs.  Maybe I don't have to avoid
them any more.  However, the ones I have seen recently are no better
than the ones I was seeing 3 or 4 years ago, and they still involve
extra clicks, extra typing, and eyestrain.  For blog comments, a
CAPTCHA invariably means I'll move on.

I'd also like to see evidence that CAPTCHAs work better than other
efforts at confusing the attacker.

 > M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re:
 > CAPTCHAs~Understanding CAPTCHA-Solving Services in an Economic
 > Context. Proceedings of the USENIX Security Symposium, Washington,
 > D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf
 > 
 > ABSTRACT
 > 
 > Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense
 > used to protect open Web resources from being exploited at scale. An
 > effective CAPTCHA resists existing mechanistic software solving, yet
 > can be solved with high probability by a human being. In response, a
 > robust solving ecosystem has emerged, reselling both automated solving
 > technology and real-time human labor to bypass these
 > protections. Thus, CAPTCHAs can increasingly be understood and
 > evaluated in purely economic terms; the market price of a solution vs
 > the monetizable value of the asset being protected. We examine the
 > market-side of this question in depth, analyzing the behavior and
 > dynamics of CAPTCHA-solving service providers, their price
 > performance, and the underlying labor markets driving this economy.

Heck, I could have written that paper.

 > So I'm going to disagree with your premise that CAPTCHAs are
 > necessarily annoying to most people unless you give more than
 > anecdotal evidence that that is the case,

There are plenty of studies showing that every extra click is costly.
What I mean by "annoying" is "increases the probability of an exit
click vs. staying on this site".

 > and I'm going to disagree that they are always or even usually
 > useless for protecting parts of WUIs.

The question is "what are they protecting?"  My claim is that if
you're protecting economic resources (bandwidth, accurate counts of
real users) they may be more or less useful.  If it's a security issue
-- including ways of harvesting email addresses that involve
subscribing -- though, you're busted.

 > > (2) it should need to be enabled by the site admin (and off by
 > > default);
 > 
 > Agreed, but only to the extent that having it available by default
 > would add a dependency, which is too much of a burden on the MM team.

Mailman should clearly not provide any CAPTCHA implementation itself,
given your claims of rapid progress in the field.

 > > (3) both configuration tools should have documentation indicating that
 > > captchas do not provide security; what they do is chase off the
 > > frivolous (both bona fide users and would-be abusers).  This is a
 > > genuine benefit in several ways for many lists; it's just not real
 > > security because serious abusers will get through.
 > 
 > Disagree. This is like saying that putting a $30 (USD) cable lock on
 > my bike is not security because serious thieves could defeat it with a
 > large pair of bolt cutters.

Yes, exactly.  My point is that you and I understand defense in depth
and the economic aspects of security; most people think in terms of
privacy leaks or hacking the financial system, which is far more
severe than the loss of a bicycle.

 > Mind you, I use a ~$100 (USD) chain lock on my bikes, but that
 > doesn't mean the $30 (USD) cable lock is useless,

It is where I live.  My $25 USD (1982 prices) Kryptonite lock is still
in service, and I have never lost a bike when using it.  I did lose a
$150 bike with a 4000 yen (1993 prices, ~$30) chain lock on it, in
less than 4 months, though.

 > You seem to think that only $100 (USD) chain locks are worth the
 > effort,

In fact, for the bike lock, I do.  A good bike lock lasts forever
(unless the thieves take the whole bike rack, nothing's perfect ;-).
Unless you know your bike-riding life will last less than a year,
there's no real point in buying less than than best bike lock
available.  Note how much knowledge and planning is required to make a
good decision here!  Computers are even harder

This is not true for computer network services, however, where the
stakes are higher and defense in depth is necessary.

 > and that I'm insisting people use cheap locks.

No, that's not my claim.  My claim is that it 

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 13, 2010, at 05:16 PM, Cristóbal Palmer wrote:

>If there's some other non-CAPTCHA approach (or set of approaches) that
>we could use to help reduce spammy signups, then I'm all for it. I
>guess my hope is that we'd have something in place that reduces the
>signups themselves rather than imposing work or workflow changes on
>moderators or list members after they've joined. If that's necessary,
>fine, but let's try things that happen at the signup step, too, yes?
>
>Even something as simple as requiring a hidden form field NONCE and
>conservative rate limits on public signups, neither of which require
>javascript or images

Given that all signups require an email validation step, and that we'll
rate-limit that to prevent using signups as a spam vector, what additional
protection does captcha provide?

-Barry



signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Cristóbal Palmer]

Before getting into this (long) reply, I want to re-emphasize that
what I want is (1) the ability to plug in existing CAPTCHA systems
(notably reCAPTCHA) quickly and easily, and change simple config
settings to enable those CAPTCHAs for parts of the interface that have
been tested and confirmed to make sense. And (2) I want other
(non-CAPTCHA, probably transparent to most users) changes to some
points (eg. new user signup, moderator login) in the default MM
interface that are designed to reduce abuse. I want (1) merely to the
extent that it helps with (2). With that, more reply below.

On Tue, Jun 15, 2010 at 01:15:47PM +0900, Stephen J. Turnbull wrote:
> "Not every three-line patch needs to be a standard feature."  Or
> 300-line patch, for that matter.  But some do.  Are captchas a feature
> that ordinary Mailman users need?  Or are they something that "if you
> know enough to know why you need them, you know enough to code an
> appropriate Handler"?  (Or snaffle one from the CheeseShop, for that
> matter.)  I have my opinion ;-), but I'm willing to be corrected. :-|

While I could in theory maintain a patch, I have a lot of machines to
herd, and I am unlikely to customize anything unless I must do so in
order to meet a requirement. I very much want upstream to maintain
anything that is reasonable and I will configure within the parameters
set by them. This is not an issue of my expertise. This is an issue of
maintainability and good use of admin time.

> I subscribe to a *lot* of Mailman lists.

So do I, but neither of us can claim (as individuals) to be
representative of mailman users (subscribers, moderators, list owners,
etc.), and in this case our claims seem to clash, so we need to look
elsewhere.

> I would be mildly annoyed if
> uninformed list owners started using captchas just because they're
> easy to configure and because a lot of big names use them.  At this
> point, I don't see a good reason to make it easy to annoy millions of
> subscribers that way.

While I share your distaste for bad implementations of... anything,
really, CAPTCHAs do not annoy me unless they are poorly implemented,
and they do not have to be poorly implemented. If you're going to say
that millions of subscribers are going to be annoyed, please cite some
studies. Here, I'll start:

(As an aside, please contact me off-list if you're not able to access
the full text for one or more of the papers cited below, and I will
arrange for you to have access.)

(1)

Yan, J. and El Ahmad, A. S. 2008. Usability of CAPTCHAs or usability
issues in CAPTCHA design. In Proceedings of the 4th Symposium on
Usable Privacy and Security (Pittsburgh, Pennsylvania, July 23 - 25,
2008). SOUPS '08, vol. 337. ACM, New York, NY, 44-52. DOI=
http://doi.acm.org/10.1145/1408664.1408671

ABSTRACT

CAPTCHA is now almost a standard security technology, and has found
widespread application in commercial websites. Usability and
robustness are two fundamental issues with CAPTCHA, and they often
interconnect with each other. This paper discusses usability issues
that should be considered and addressed in the design of
CAPTCHAs. Some of these issues are intuitive, but some others have
subtle implications for robustness (or security). A simple but novel
framework for examining CAPTCHA usability is also proposed.

(2)

Bigham, J. P. and Cavender, A. C. 2009. Evaluating existing audio
CAPTCHAs and an interface optimized for non-visual use. In Proceedings
of the 27th international Conference on Human Factors in Computing
Systems (Boston, MA, USA, April 04 - 09, 2009). CHI '09. ACM, New
York, NY, 1829-1838. DOI= http://doi.acm.org/10.1145/1518701.1518983

ABSTRACT

Audio CAPTCHAs were introduced as an accessible alternative for those
unable to use the more common visual CAPTCHAs, but anecdotal accounts
have suggested that they may be more difficult to solve. This paper
demonstrates in a large study of more than 150 participants that
existing audio CAPTCHAs are clearly more difficult and time-consuming
to complete as compared to visual CAPTCHAs for both blind and sighted
users. In order to address this concern, we developed and evaluated a
new interface for solving CAPTCHAs optimized for non-visual use that
can be added in-place to existing audio CAPTCHAs. In a subsequent
study, the optimized interface increased the success rate of blind
participants by 59% on audio CAPTCHAs, illustrating a broadly
applicable principle of accessible design: the most usable audio
interfaces are often not direct translations of existing visual
interfaces.

And finally, my favorite: (3)

M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re:
CAPTCHAs–Understanding CAPTCHA-Solving Services in an Economic
Context. Proceedings of the USENIX Security Symposium, Washington,
D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf

ABSTRACT

Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense
used to protect open Web resources from being exploited at scale. An
e

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Eric Bloch writes:

 > My experience is not limited nor second hand.  We get scanned by
 > plenty of bots every day.

Heck, I can beat that: some of my sites get scanned by more bots than
they have actual users.  The question of "limited" is "how many
different sites/kinds of sites do you have experience (eg, log access)
on?"  In my case, it's a half dozen or so, plus the talk I hear from
other admins in the LUGs etc I hang out with.  You can surely beat
that, but does your experience generalize to a large fraction of
Mailman lists, so that it should be a standard option provided by
Mailman?

"Not every three-line patch needs to be a standard feature."  Or
300-line patch, for that matter.  But some do.  Are captchas a feature
that ordinary Mailman users need?  Or are they something that "if you
know enough to know why you need them, you know enough to code an
appropriate Handler"?  (Or snaffle one from the CheeseShop, for that
matter.)  I have my opinion ;-), but I'm willing to be corrected. :-|

 > We also see captchas broken every day by some bots.  Not all bots
 > break the captchas.  Not all are trying to, either of course.

This is the post hoc part.  Of course, you see this, I was assuming
you do.

 > But without the captchas, the ones that weren't even trying would
 > be getting to things we don't want them to get at.  It's that
 > simple.

This is the propter hoc part.  It's not that simple.  Captcha-using
pages are *different* from non-captcha pages.  What is it in your
experience that shows that the captcha has any additional effect
compared to *other* differences that are less annoying to bona fide
users?

I subscribe to a *lot* of Mailman lists.  I would be mildly annoyed if
uninformed list owners started using captchas just because they're
easy to configure and because a lot of big names use them.  At this
point, I don't see a good reason to make it easy to annoy millions of
subscribers that way.  Or lose them, for that matter; I'm an Anonymous
Coward on more than one site because I couldn't be bothered to use my
"neural network" to break the captchas.  Especially in open source
development, the "frivolous" contributions (eg, one-off bug reports)
add up --- we really don't want to encourage "features" of known cost
to the individual subscriber and dubious benefit to the list community.

Not to mention that this is an "arms race game": the more captchas are
used, the more 'bots will be programmed to recognize *and break* them.
You admit that you already see successful break-ins "every day", and
the rate will only increase.  They're really mostly suitable for well-
informed admins who understand concepts like "defense in depth".  (But
again, those folks can typically cons up a patch pretty quickly.  These
parts of Mailman are not that hard to modify, especially in Mailman 3.)

I guess my bottom line is that if a captcha feature is provided
standard in Mailman 3, I believe that

(1) it should be configurable per list (and off by default);

(2) it should need to be enabled by the site admin (and off by
default);

The rationale for this is not just to make it harder to use the
feature, but that the site admin is likely to be more expert in
general to understand the limitations of the feature, and also
some of the benefits and costs accrue to the site rather to the
list community, so the site admin should have some input.

(3) both configuration tools should have documentation indicating that
captchas do not provide security; what they do is chase off the
frivolous (both bona fide users and would-be abusers).  This is a
genuine benefit in several ways for many lists; it's just not real
security because serious abusers will get through.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Eric Bloch]

My experience is not limited nor second hand.  We get scanned by plenty of bots 
every day.
We also see captchas broken every day by some bots.  Not all bots break the 
captchas.  Not 
all are trying to, either of course.But without the captchas, the ones that 
weren't even trying
would be getting to things we don't want them to get at.  It's that simple.  
Not a solution, just a screen door
in the way - one that I don't mind asking my users to open up by hand as they 
come in.


-Eric


From: Stephen J. Turnbull [step...@xemacs.org]
Sent: Monday, June 14, 2010 7:11 PM
To: Eric Bloch
Cc: Cristóbal Palmer; mailman-developers@python.org
Subject: Re: [Mailman-Developers] UI for Mailman 3.0 update

Eric Bloch writes:

 > I am a lurker here and can concur with Cristóbal's sentiments wrt
 > captchas .  I run http://markmail.org where we provide a search
 > index for thousands of public mailman lists (and google groups and
 > other mailing lists as well).  The captchas we use (for a variety
 > of purposes) aren't perfect, but they get rid of a lot of junk.

How do you know?  "Post hoc ergo propter hoc" is a fallacy.

In my (limited and often second-hand) experience, *any* change to a
form reduces "junk" dramatically.  Simply using obfuscated names for
signup fields (such as swapping the email address variable name and
the full name variable name) often reduces signups (presumably the
difference is 'bots) significantly.  I've heard one report that
switching from a homebrew CMS to Drupal (IIRC) was followed by a
dramatic increase in signups ... most of the increase being bogus.
Nothing against Drupal, just that it apparently provides standard
forms for certain purposes, and 'bots take advantage.  Any standard
and common system (eg, Mailman) which recruits members would face the
same problem.

Do cosmetic changes work as well as captcha?  I don't know.  I do know
that about 2 years ago I downloaded one of the gocr-based captcha
breakers and watched it get 5% to 40% success rates against a
star-studded cast (don't recall exactly, but the likes of Google and
Yahoo were in there).  95% "correct" answers may sound good to a
college student taking a final exam, but what that means in the case
of captchas is bogus signups at a maximum rate of about 3/min.  Oops.

My conclusion (lacking other data) is that the cost of annoying my
users is far greater than the potential benefit.  I don't intend to
even try to collect real data on captcha efficacy. ;-)
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Eric Bloch writes:

 > I am a lurker here and can concur with Cristóbal's sentiments wrt
 > captchas .  I run http://markmail.org where we provide a search
 > index for thousands of public mailman lists (and google groups and
 > other mailing lists as well).  The captchas we use (for a variety
 > of purposes) aren't perfect, but they get rid of a lot of junk.

How do you know?  "Post hoc ergo propter hoc" is a fallacy.

In my (limited and often second-hand) experience, *any* change to a
form reduces "junk" dramatically.  Simply using obfuscated names for
signup fields (such as swapping the email address variable name and
the full name variable name) often reduces signups (presumably the
difference is 'bots) significantly.  I've heard one report that
switching from a homebrew CMS to Drupal (IIRC) was followed by a
dramatic increase in signups ... most of the increase being bogus.
Nothing against Drupal, just that it apparently provides standard
forms for certain purposes, and 'bots take advantage.  Any standard
and common system (eg, Mailman) which recruits members would face the
same problem.

Do cosmetic changes work as well as captcha?  I don't know.  I do know
that about 2 years ago I downloaded one of the gocr-based captcha
breakers and watched it get 5% to 40% success rates against a
star-studded cast (don't recall exactly, but the likes of Google and
Yahoo were in there).  95% "correct" answers may sound good to a
college student taking a final exam, but what that means in the case
of captchas is bogus signups at a maximum rate of about 3/min.  Oops.

My conclusion (lacking other data) is that the cost of annoying my
users is far greater than the potential benefit.  I don't intend to
even try to collect real data on captcha efficacy. ;-)
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Eric Bloch]

I am a lurker here and can concur with Cristóbal's sentiments wrt captchas .  I 
run http://markmail.org where we provide a search index for thousands of public 
mailman lists (and google groups and other mailing lists as well).  The 
captchas we use (for a variety of purposes) aren't perfect, but they get rid of 
a lot of junk.  

-Eric




> But, captchas?  Pre-defeated.

With all due respect to your experience, I don't think CAPTCHAs as a
class have been defeated, in the sense that the goal is not to
completely defeat all spam, but rather the goal is to mitigate at
relatively low cost to ourselves and at high cost to the spammers, and
from personal experience I can say that reCAPTCHA has served that
purpose well when I have deployed it.


___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Cristóbal Palmer]

On Tue, Jun 08, 2010 at 10:12:18PM -0400, Rich Kulawiec wrote:
> > could have MM3 ship with a CAPTCHA system and/or support for a class
> > of CAPTCHA systems in the default web UI, that would be super.
 
I'd like to re-emphasize the fact that what I would like is some sort
of plugin support. Want this kind of CAPTCHA? Take these simple
steps

> But, captchas?  Pre-defeated.

With all due respect to your experience, I don't think CAPTCHAs as a
class have been defeated, in the sense that the goal is not to
completely defeat all spam, but rather the goal is to mitigate at
relatively low cost to ourselves and at high cost to the spammers, and
from personal experience I can say that reCAPTCHA has served that
purpose well when I have deployed it.

If there's some other non-CAPTCHA approach (or set of approaches) that
we could use to help reduce spammy signups, then I'm all for it. I
guess my hope is that we'd have something in place that reduces the
signups themselves rather than imposing work or workflow changes on
moderators or list members after they've joined. If that's necessary,
fine, but let's try things that happen at the signup step, too, yes?

Even something as simple as requiring a hidden form field NONCE and
conservative rate limits on public signups, neither of which require
javascript or images

Cheers,
-- 
Cristóbal Palmer
ibiblio.org
metalab.unc.edu
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Rich Kulawiec]

On Sun, Jun 06, 2010 at 04:29:14PM -0400, Crist?bal Palmer wrote:
> The ability to use reCAPTCHA or other CAPTCHA systems as part of the
> web signup would also significantly reduce spammy signups, so if we
> could have MM3 ship with a CAPTCHA system and/or support for a class
> of CAPTCHA systems in the default web UI, that would be super.

No, it won't.  Spammers have quite thoroughly defeated these, years
ago, via an assortment of techniques.  Yes, some deployments don't
see this: they're not considered important enough to attack.  But
as Yahoo most recently found (and they're only the most recent entry
in a long parade) when spammers or other abusers decide it's time,
they can rapidly solve them by the tens of thousands.

Moreover, there's really no need for spammers to trouble themselves
with this approach.  If the goal is address-harvesting, then there
are far more efficient ways that yield much better results.  If the
goal is to spam the list, then it's much easier to hijack an
already-subscribed account -- particularly if it's located at one
of the many freemail providers whose security is weak, but alternatively
by via the subscriber's own system.

There does not exist a truly effective defense against these attack
vectors for lists of substantial size.  (Very small lists can be defended
by limiting membership, mail account location and operating system but
these are clearly special cases and these tactics don't scale.)
This isn't surprising, nor is it Mailman's fault: when the adversary
owns so much infrastructure, it's just not going to be possible to
craft defenses that work other than temporarily and accidentally.

One mitigation step -- and it's not a terribly good one, but at least
it's one with minimal impact -- is to employ the policy that list
subscribers posting from freemail providers are always moderated.
Of course this only intercepts one vector and of course it requires
manual intervention -- which is why I *said* it's not terribly good.
But experiments I've run indicate that at least for the moment, it
deals with the most likely attack vector, and it has the virtue of
using an existing mechanism.

But, captchas?  Pre-defeated.

---Rsk
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[David Andrews]

At 02:50 PM 6/6/2010, Patrick Ben Koetter wrote:


Great. I can see and I need to use my imagination to figure what a _real
good_ interface for visually imapaired people looks like. Better to have
people who really know from first hand experience what to look out for.

This said I think the interface should also be better accessible for deaf
people. I've learned deaf people experience problems with complex sentences.
We should consider that too and other aspects.



Well, you probably wouldn't like the look or feel of an interface I 
would design for myself as a blind person.  No danger of having to 
suffer through it anyway, as I am not a developer.  I think I started 
this thread a couple days ago, and my point was, and is, that if WCAG 
2.0 guidelines are followed, the UI can look however you guys want, 
but still meet the needs of blind and other disabled users -- 
including the deaf.


I am not a developer -- but run a bunch of lists and have a little 
experience at web site accessibility testing and would be pleased to 
help out in that area in any way I can.


Dave




David Andrews:  dandr...@visi.com
Follow me on Twitter:  http://www.twitter.com/dandrews920

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 07, 2010, at 09:16 AM, Patrick Ben Koetter wrote:

>That would be perfect. Should we all meet before we start working on the new
>WUI so we can take the input into consideration right from the start?

Although I wouldn't be able to make that in person, please do use the bug
tracker to request any new features of the REST interface.  You can always tag
them with 'mailman3' to get my attention.

-Barry



signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Anna Granudd]

I could look into reorganizing the pages since I'll be working with the UI
anyways but I'm not sure how to "gard" them (might be that I don't have the
rights to do so though)? Anyone else willing to help out is of course
welcome to do so.

Anna

On Mon, Jun 7, 2010 at 8:41 PM, Barry Warsaw  wrote:

> ...
> Probably start here:
>
> http://wiki.list.org/display/DEV/Web+Interface
>
> but I think with the ramp up of work on the wui, these pages could use some
> gardening and reorganization.  Any volunteers?
>
> -Barry
>
> ___
> 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/anna.granudd%40gmail.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 06, 2010, at 09:50 PM, Patrick Ben Koetter wrote:

>For this summer (of code) Anna has joined the team and I believe if Barry
>manages to do more work on the REST server and IMAP backend - *HINT* *HINT* -
>we will soon be able to present an early version of MM3 to test and play with
>while we bring it to a stable state.

Hint taken. :)

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 05, 2010, at 07:52 PM, Geoff Shang wrote:

>I realise that Mailman 3.x will make it possible to create multiple UIs, 
>as the functionality will be separated from the UI.  However, it is also 
>my experience that alternate/specialised UIs can and do go unmaintained, 
>and as such it is my hope that the (or at least a) standard UI shipped by 
>default with Mailman will provide the needed accessibility.
>
>So this is one of the reasons why I'm on this list, to keep an eye on 
>developments and hopefully provide some feedback when a test server 
>becomes available.

That's great Geoff, we appreciate all your help in understanding the issues
and driving toward a ui that's at least as usable as the MM 2.1 interface is.

I have a general question though: given that Mailman 3 will be scriptable, is
that a better long term solution than screen scraping?  We still need to work
out the security model for public access (i.e. OAuth, a proxy to the internal
admin interface, etc), but I think it'll be very cool to write the scripts you
want and actually interact with Mailman without using a wui.

>1.  At least one UI with no *necessary* javascript. Maybe this won't be 
>the main UI, but as a person who uses the Linux console with a text-mode 
>browser, I like the fact that I can quickly fire up my browser to deal 
>with a moderator request with no fuss.  Given that a package like 
>Squirrelmail can operate completely without Javascript if the user 
>chooses, this should surely be possible.

+1.  We want links/lynx users to be able to use the site.

>2.  Proper use of the label tag in association with form elements.  This 
>was (or seemed to be done) fairly well for the most part, with the 
>exception of those checkboxes I mentioned, but I'd hate to see this lost. 
>What this means in practice is that screen readers will read the 
>appropriate label text when focusing upon a form element.
>
>There's probably other important stuff, but this is all that comes to mind 
>right now.
>
>Other non-accessibility-related things which I think are worth considering 
>are:
>
>1.  More useful archives with search capability.  I'm sure this is on a 
>dozen wishlists.

Indeed. :)  You know that song by the Bare Naked Ladies?  Well, if *I* had a
million dollars, I'd write a killer new open source mail archiver. :)

>2.  A friendlier front page per list.  Surely having 3 forms on the front 
>page (or is it 4?) is a bit intimidating to some.

Definitely.

>I've got some other feature requests based on 2.1.x functionality but I'll 
>post that somewhere else more appropriate.

Looking forward to it!
-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 06, 2010, at 04:29 PM, Cristóbal Palmer wrote:

>On Fri, Jun 04, 2010 at 09:58:12AM -0700, Mark Sapiro wrote:
>> 
>> As Barry suggests, setting moderation of new members as the default can
>> also thwart the subscribing spammers.
>
>The ability to use reCAPTCHA or other CAPTCHA systems as part of the
>web signup would also significantly reduce spammy signups, so if we
>could have MM3 ship with a CAPTCHA system and/or support for a class
>of CAPTCHA systems in the default web UI, that would be super.

I personally hate captcha systems because I think they all have horrible
usability issues.  But I understand the appeal so I think I would vote against
enabling such things by default, but would support allowing it to be added
fairly easily.

>Is there a good place in the wiki for me to stick this suggestion, or
>will somebody who knows where it should go do that?

Probably start here:

http://wiki.list.org/display/DEV/Web+Interface

but I think with the ramp up of work on the wui, these pages could use some
gardening and reorganization.  Any volunteers?

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Anna Granudd]

On Mon, Jun 7, 2010 at 12:00 PM,  wrote:

> ...

>That would be perfect. Should we all meet before we start working on the
> new

 >WUI so we can take the input into consideration right from the start?


> IMHO it is easier to talk / discuss about real things than about things
> that should be done theoreticaly :). So I'd suggest to meet if a early
>  draft of the new WUI is available.
>

Please keep the rest of us, or at least myself and Florian, posted about
your discussions when meeting IRL. I believe you Patrick work together with
Florian so I guess that should be easy enough. :) In German or English
doesn't really matter unless you want to post it to this list...

Thanks,
Anna
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Christian Schoepplein]

On Mon, Jun 07, 2010 at 09:16:58AM +0200, Patrick Ben Koetter wrote:
>* Christian Schoepplein :
>> >* Geoff Shang :
>> >> Note that people who use magnification (i.e. who have low vision)
>> >> are going to have differing requirements from those who use speech
>> >> or Braille output via screen readers.  Ideally the UI would work
>> >> well for both groups but I'm not qualified to talk about the former,
>> >> only the latter.
>> >
>> >Yes, thank you. I was aware of that and I have to admit I don't know yet 
>> >what
>> >qualities exactly will be required to create an interface that works equally
>> >well for both groups. Unless someone has a better idea I guess we will just
>> >have to do 'a best guess', then measure and improve in an iterative manner.
>> 
>> I know some people that use magnification. I can ask them to test also the 
>> new MM WUI or ask them for their needs regarding a new user interface.
>
>Great.
>
>> >> Disclaimer: I am not deaf.  A deaf person should be consulted about
>> >> the requirements that deaf people may have.
>> >
>> >Yes, good idea. Are there any deaf people on this list who might be able to
>> >shed some light on this?
>> 
>> I also can help out on this point maybe, because I also have friends 
>> that are deaf or work for a big German organization for deaf people.
>
>Even better.
>
>> @p...@trick: Maybe I can also arrange a meeting with these people, they also 
>> live in Munich.
>
>That would be perfect. Should we all meet before we start working on the new
>WUI so we can take the input into consideration right from the start?

IMHO it is easier to talk / discuss about real things than about things 
that should be done theoreticaly :). So I'd suggest to meet if a early 
draft of the new WUI is available.


Regards,

  Schoepp

-- 
Christian Schoepplein 



signature.asc
Description: Digital signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Patrick Ben Koetter]

* Christian Schoepplein :
> >* Geoff Shang :
> >> Note that people who use magnification (i.e. who have low vision)
> >> are going to have differing requirements from those who use speech
> >> or Braille output via screen readers.  Ideally the UI would work
> >> well for both groups but I'm not qualified to talk about the former,
> >> only the latter.
> >
> >Yes, thank you. I was aware of that and I have to admit I don't know yet what
> >qualities exactly will be required to create an interface that works equally
> >well for both groups. Unless someone has a better idea I guess we will just
> >have to do 'a best guess', then measure and improve in an iterative manner.
> 
> I know some people that use magnification. I can ask them to test also the 
> new MM WUI or ask them for their needs regarding a new user interface.

Great.

> >> Disclaimer: I am not deaf.  A deaf person should be consulted about
> >> the requirements that deaf people may have.
> >
> >Yes, good idea. Are there any deaf people on this list who might be able to
> >shed some light on this?
> 
> I also can help out on this point maybe, because I also have friends 
> that are deaf or work for a big German organization for deaf people.

Even better.

> @p...@trick: Maybe I can also arrange a meeting with these people, they also 
> live in Munich.

That would be perfect. Should we all meet before we start working on the new
WUI so we can take the input into consideration right from the start?

p...@rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 München  Telefax +49 89 3090 4666

Amtsgericht MünchenPartnerschaftsregister PR 563


signature.asc
Description: Digital signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Christian Schoepplein]

On Sun, Jun 06, 2010 at 11:44:07PM +0200, Patrick Ben Koetter wrote:
>* Geoff Shang :
>> Note that people who use magnification (i.e. who have low vision)
>> are going to have differing requirements from those who use speech
>> or Braille output via screen readers.  Ideally the UI would work
>> well for both groups but I'm not qualified to talk about the former,
>> only the latter.
>
>Yes, thank you. I was aware of that and I have to admit I don't know yet what
>qualities exactly will be required to create an interface that works equally
>well for both groups. Unless someone has a better idea I guess we will just
>have to do 'a best guess', then measure and improve in an iterative manner.

I know some people that use magnification. I can ask them to test also the 
new MM WUI or ask them for their needs regarding a new user interface.

>> Disclaimer: I am not deaf.  A deaf person should be consulted about
>> the requirements that deaf people may have.
>
>Yes, good idea. Are there any deaf people on this list who might be able to
>shed some light on this?

I also can help out on this point maybe, because I also have friends 
that are deaf or work for a big German organization for deaf people.

@p...@trick: Maybe I can also arrange a meeting with these people, they also 
live in Munich.

Regards,

  Schoepp

-- 

Christian Schoepplein 



signature.asc
Description: Digital signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Patrick Ben Koetter writes:
 > Geoff,
 > 
 > I am really happy to find out you, as a blind person,

Yeah, a big +1 on that.  Good to hear that we can get first person
feedback.  Interesting to hear that Mailman 2 has a reasonably usable
interface, as AFAIK that wasn't a design consideration.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Stephen J. Turnbull]

Barry Warsaw writes:

 > We'll probably end up using Launchpad since our branches and bug trackers are
 > there, but Transifex does look nice.

File an RFE on Launchpad!  Then go twist some arms at the next Ubuntu
summit, or better yet, lull them into submission with slow sexy bass
line.  Maybe you can get Slowhand as the front man!

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Patrick Ben Koetter]

* Geoff Shang :
> Note that people who use magnification (i.e. who have low vision)
> are going to have differing requirements from those who use speech
> or Braille output via screen readers.  Ideally the UI would work
> well for both groups but I'm not qualified to talk about the former,
> only the latter.

Yes, thank you. I was aware of that and I have to admit I don't know yet what
qualities exactly will be required to create an interface that works equally
well for both groups. Unless someone has a better idea I guess we will just
have to do 'a best guess', then measure and improve in an iterative manner.


> >This said I think the interface should also be better accessible for deaf
> >people. I've learned deaf people experience problems with complex
> >sentences.  We should consider that too and other aspects.
> 
> Huh?  This makes no sense to me.  People who only have hearing
> impairments shouldn't have any more problems with comprehention or

It didn't make sense to me either until I listened to a Chaos Computer Club
(CCC) Podcast about accessibility with the two guys who started/participated
in the Web Standards Project . Too bad the
Podcasts are German only. I recommend them to anybody interested in technics,
society and culture.

Anyway, their story went like this: If you are deaf you learn sign language to
communicate with others. Sign language is the first (mother) language for deaf
people. Any other (written) language is foreign and that introduces all the
problems people usually have with foreign languages.

> reading than people with only vision impairments.  By all means make
> allowances for people with reading/learning/cognitive disabilities,
> but please don't atribute the need for this to something unrelated.

Do I seem overeager? Don't worry I am not a do-gooder trying to create an
interface that attempts to work for _everybody_ on this planet. I simply want
to create an interface that accounts for accessibility and that includes deaf
people too. If the relation "deaf - reading problems" stands then I'd like to
find a way that works for deaf people too.

Maybe (!) that's not a problem at all with an application interface as we are
going to create, but only with websites that contain lots of text.

> Disclaimer: I am not deaf.  A deaf person should be consulted about
> the requirements that deaf people may have.

Yes, good idea. Are there any deaf people on this list who might be able to
shed some light on this?

p...@rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 München  Telefax +49 89 3090 4666

Amtsgericht MünchenPartnerschaftsregister PR 563

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Geoff Shang]

On Sun, 6 Jun 2010, Patrick Ben Koetter wrote:


Great. I can see and I need to use my imagination to figure what a _real
good_ interface for visually imapaired people looks like. Better to have
people who really know from first hand experience what to look out for.


Note that people who use magnification (i.e. who have low vision) are 
going to have differing requirements from those who use speech or Braille 
output via screen readers.  Ideally the UI would work well for both groups 
but I'm not qualified to talk about the former, only the latter.



This said I think the interface should also be better accessible for deaf
people. I've learned deaf people experience problems with complex sentences.
We should consider that too and other aspects.


Huh?  This makes no sense to me.  People who only have hearing impairments 
shouldn't have any more problems with comprehention or reading than people 
with only vision impairments.  By all means make allowances for people 
with reading/learning/cognitive disabilities, but please don't atribute 
the need for this to something unrelated.


Disclaimer: I am not deaf.  A deaf person should be consulted about the 
requirements that deaf people may have.



Most of my other feature requests are functionality-related, rather
than UI as such.  Some may already be in the wishlist(s) on the Wiki
(or wherever I saw it).  I'm happy to post them here in a separate
thread if people think it's relevant.  They're just things I've
jotted down when using Mm that I've thought should be changed/fixed.


Please post your feature requests even if we find out they are duplicates.


Ok, will do.

Geoff.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Geoff Shang]

On Sun, 6 Jun 2010, Cristóbal Palmer wrote:


The ability to use reCAPTCHA or other CAPTCHA systems as part of the
web signup would also significantly reduce spammy signups, so if we
could have MM3 ship with a CAPTCHA system and/or support for a class
of CAPTCHA systems in the default web UI, that would be super.


I would think that having some way of plugging this in would be better 
than hard-coding it, as new solutions come along all the time.


Recaptcha is good as far as traditional captchas go, but while we're 
voting, I'll vote for Text Captcha (www.textcaptcha.com) for obvious 
reasons.  Though one available in multiple languages would be a good idea 
of course.


And it goes without saying that this only would make a difference for 
web-based subscription, it wouldn't make any difference for Email 
subscription requests unless you wanted to plug something like Text 
Captcha into the confirmation process, which would be rather novel at 
least.


Geoff.
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Patrick Ben Koetter]

* Patrick Ben Koetter :
> * Christian Schoepplein :
> > >I am really happy to find out you, as a blind person, are on this list and
> > >that you want to get involved into MM3 development, because creating a user
> > >interface that works well for most visually impaired people is one of 
> > >our/my
> > >major goals in the MM3 WUI (web user interface) overhaul.
> > 
> > That sounds very good. I also got in contact with Anna and asked about 
> > the accessibility in the new WUI, that should be an important point 
> > IMHO and should be not forgotten. Very nice that other people, who are 
> > more involved in the development of mailman, are keeping this point in 
> > mind too :).
> > 
> > As allready said to Anna, just let me / us know, if there is anything to 
> > test. I'd be happy to support the development of the new WUI as good as 
> > possible regarding the accessibility for blind or visual impared users.
> 
> Great. I live near Munich. Maybe we can meet and you can give me some first
> some Sendmail bashing... ;)

That's what you get when you delete the wrong lines... :-D

I wanted to say: "Great. I live near Munich. Maybe we can meet and you can give
me some first hand experience using MM3 as a blind person."

And I was going to say something about the two of us using Postfix and we
could do some Sendmail bashing... ;)

p...@rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 München  Telefax +49 89 3090 4666

Amtsgericht MünchenPartnerschaftsregister PR 563



signature.asc
Description: Digital signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Cristóbal Palmer]

On Fri, Jun 04, 2010 at 09:58:12AM -0700, Mark Sapiro wrote:
> 
> As Barry suggests, setting moderation of new members as the default can
> also thwart the subscribing spammers.

The ability to use reCAPTCHA or other CAPTCHA systems as part of the
web signup would also significantly reduce spammy signups, so if we
could have MM3 ship with a CAPTCHA system and/or support for a class
of CAPTCHA systems in the default web UI, that would be super.

Is there a good place in the wiki for me to stick this suggestion, or
will somebody who knows where it should go do that?

Cheers,
-- 
Cristóbal Palmer
ibiblio.org
metalab.unc.edu
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Patrick Ben Koetter]

* Christian Schoepplein :
> >I am really happy to find out you, as a blind person, are on this list and
> >that you want to get involved into MM3 development, because creating a user
> >interface that works well for most visually impaired people is one of our/my
> >major goals in the MM3 WUI (web user interface) overhaul.
> 
> That sounds very good. I also got in contact with Anna and asked about 
> the accessibility in the new WUI, that should be an important point 
> IMHO and should be not forgotten. Very nice that other people, who are 
> more involved in the development of mailman, are keeping this point in 
> mind too :).
> 
> As allready said to Anna, just let me / us know, if there is anything to 
> test. I'd be happy to support the development of the new WUI as good as 
> possible regarding the accessibility for blind or visual impared users.

Great. I live near Munich. Maybe we can meet and you can give me some first
some Sendmail bashing... ;)

p...@rick


-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 München  Telefax +49 89 3090 4666

Amtsgericht MünchenPartnerschaftsregister PR 563



signature.asc
Description: Digital signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Patrick Ben Koetter]

* Geoff Shang :
> I was mainly wanting to highlight my accessibility concerns,
> particularly since I couldn't see the mock-ups, but I agree with all
> your points.

Great. I can see and I need to use my imagination to figure what a _real
good_ interface for visually imapaired people looks like. Better to have
people who really know from first hand experience what to look out for.

This said I think the interface should also be better accessible for deaf
people. I've learned deaf people experience problems with complex sentences.
We should consider that too and other aspects.

> >You mentioned "some other feature requests based on 2.1.x functionality". I'd
> >be curious to learn what they are and even more than that I would like to
> >invite you to help us create a user interface that works for as many as
> >possible.
> 
> Most of my other feature requests are functionality-related, rather
> than UI as such.  Some may already be in the wishlist(s) on the Wiki
> (or wherever I saw it).  I'm happy to post them here in a separate
> thread if people think it's relevant.  They're just things I've
> jotted down when using Mm that I've thought should be changed/fixed.

Please post your feature requests even if we find out they are duplicates.


> As for UI development, I'm fairly rusty at Python and I've never
> actually used Django (though I like the look of it), but I'd be
> happy to get my hands dirty if it's a matter of tweeking what
> someone else has started.

You are more than welcome to help. As far as I know MM3 development has taken
place mostly in sprints at Pycons in 2009 and 2010 (I don't recall everybodys
name right now) and after these events almost solely by Barry and Florian.

For this summer (of code) Anna has joined the team and I believe if Barry
manages to do more work on the REST server and IMAP backend - *HINT* *HINT* -
we will soon be able to present an early version of MM3 to test and play with
while we bring it to a stable state.

p...@rick

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 München  Telefax +49 89 3090 4666

Amtsgericht MünchenPartnerschaftsregister PR 563

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Geoff Shang]

On Sat, 5 Jun 2010, Patrick Ben Koetter wrote:


I am really happy to find out you, as a blind person, are on this list and
that you want to get involved into MM3 development, because creating a user
interface that works well for most visually impaired people is one of our/my
major goals in the MM3 WUI (web user interface) overhaul.


Glad to hear it.  I've been using Mm successfully in varius capacities 
for 10 years, so I have some experience of using it.  I've only recently 
taken on site admin tasks with it, which is when I decided to jump on the 
mailing lists.



This said: I believe the current interface is too complicated even for those
who don't need to meet any perceptional or motional challenges:


Oh I can see the issues.  I think its served us nurdy types reasonably 
well for some time, but as you say, it's not very logical in the way it 
does things.


I was mainly wanting to highlight my accessibility concerns, particularly 
since I couldn't see the mock-ups, but I agree with all your points.



But JavaScript et al. must not be a basic requirement. We want progressive
enhancement  and, to
answer one of your questions in your message, our goal is to ship a default
user interface that provides the needed accessibility.


I'm glad to hear it, and I'm sure others will be also.


You mentioned "some other feature requests based on 2.1.x functionality". I'd
be curious to learn what they are and even more than that I would like to
invite you to help us create a user interface that works for as many as
possible.


Most of my other feature requests are functionality-related, rather than 
UI as such.  Some may already be in the wishlist(s) on the Wiki (or 
wherever I saw it).  I'm happy to post them here in a separate thread if 
people think it's relevant.  They're just things I've jotted down when 
using Mm that I've thought should be changed/fixed.


As for UI development, I'm fairly rusty at Python and I've never actually 
used Django (though I like the look of it), but I'd be happy to get my 
hands dirty if it's a matter of tweeking what someone else has started.


Geoff.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Christian Schoepplein]

Hi p...@trick,

On Sat, Jun 05, 2010 at 11:59:31PM +0200, Patrick Ben Koetter wrote:
>Geoff,
>
>I am really happy to find out you, as a blind person, are on this list and
>that you want to get involved into MM3 development, because creating a user
>interface that works well for most visually impaired people is one of our/my
>major goals in the MM3 WUI (web user interface) overhaul.

That sounds very good. I also got in contact with Anna and asked about 
the accessibility in the new WUI, that should be an important point 
IMHO and should be not forgotten. Very nice that other people, who are 
more involved in the development of mailman, are keeping this point in 
mind too :).

As allready said to Anna, just let me / us know, if there is anything to 
test. I'd be happy to support the development of the new WUI as good as 
possible regarding the accessibility for blind or visual impared users.

Regards from Munic,

  Schoepp

-- 
Christian Schoepplein 


signature.asc
Description: Digital signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Patrick Ben Koetter]

Geoff,

I am really happy to find out you, as a blind person, are on this list and
that you want to get involved into MM3 development, because creating a user
interface that works well for most visually impaired people is one of our/my
major goals in the MM3 WUI (web user interface) overhaul.

This said: I believe the current interface is too complicated even for those
who don't need to meet any perceptional or motional challenges:

- It doesn't enforce reasonable grouping of related functions
- It exposes an immense number of configuration options to the user but
  doesn't seem to prioritize how often they are required
- It has a high signal noise ratio i.e. it's crowed with text (help messages)
  which makes it hard to focus on the configuration options themselves.
- HTML is not used in a semantic way. You already mentioned there's no
  association between option names and their fields aka 'labels'. If I
  remember correctly structure i.e. headings and reasonable use of list are
  also missing.

The list is totally uncomplete, but I guess you get the idea.

This and more should go and be replaced by better solutions AND the interface
should be modern, nice to look at and provide a set of comfortable JavaScript
functions.

But JavaScript et al. must not be a basic requirement. We want progressive
enhancement  and, to
answer one of your questions in your message, our goal is to ship a default
user interface that provides the needed accessibility.

You mentioned "some other feature requests based on 2.1.x functionality". I'd
be curious to learn what they are and even more than that I would like to
invite you to help us create a user interface that works for as many as
possible.

p...@rick


* Geoff Shang :
> On Fri, 4 Jun 2010, Anna Granudd wrote:
> 
> >there are some mock-ups on the wiki (see
> >http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you
> >could help with ideas for a nice design and layout!
> 
> As a blind person, I'm not able to comment on these as these are images.
> 
> I can understand the desire for an overhall of the Mailman UI, but I
> think it's worth saying that for the most part, the 2.x UI works
> well for people using screen reader technology.  The only area which
> provides some challenges is the membership management screen, as it
> can be difficult to associate each checkbox with the function it
> performs.  But even this can be managed using screen reader commands
> for reading tables.
> 
> I realise that Mailman 3.x will make it possible to create multiple
> UIs, as the functionality will be separated from the UI.  However,
> it is also my experience that alternate/specialised UIs can and do
> go unmaintained, and as such it is my hope that the (or at least a)
> standard UI shipped by default with Mailman will provide the needed
> accessibility.
> 
> So this is one of the reasons why I'm on this list, to keep an eye
> on developments and hopefully provide some feedback when a test
> server becomes available.
> 
> Right now, my UI wishlist is as follows:
> 
> 1.  At least one UI with no *necessary* javascript. Maybe this won't
> be the main UI, but as a person who uses the Linux console with a
> text-mode browser, I like the fact that I can quickly fire up my
> browser to deal with a moderator request with no fuss.  Given that a
> package like Squirrelmail can operate completely without Javascript
> if the user chooses, this should surely be possible.
> 
> 2.  Proper use of the label tag in association with form elements.
> This was (or seemed to be done) fairly well for the most part, with
> the exception of those checkboxes I mentioned, but I'd hate to see
> this lost. What this means in practice is that screen readers will
> read the appropriate label text when focusing upon a form element.
> 
> There's probably other important stuff, but this is all that comes
> to mind right now.
> 
> Other non-accessibility-related things which I think are worth
> considering are:
> 
> 1.  More useful archives with search capability.  I'm sure this is
> on a dozen wishlists.
> 
> 2.  A friendlier front page per list.  Surely having 3 forms on the
> front page (or is it 4?) is a bit intimidating to some.
> 
> I've got some other feature requests based on 2.1.x functionality
> but I'll post that somewhere else more appropriate.
> 
> Geoff.
> 
> ___
> 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/p%40state-of-mind.de
> 
> Security Policy: http://wiki.list.org/x/QIA9

-- 
state of mind
Digitale Kommunikation

http://www.state-of-mind.de

Franziskanerstraße 15  Telefon +49 89 3090 4664
81669 Münc

Re: [Mailman-Developers] UI for Mailman 3.0 update

[David Andrews]

At 07:29 AM 6/3/2010, Anna Granudd wrote:

Hi,
my name is Anna and I'm participating in GSoC for Systers where my project
this summer is to develop a new UI for Mailman 3.0 as well as a UI extension
for Systers who are running a customized version of Mailman. The UI will be
written as an app in Django. Together with my mentor Florian we've discussed
some general matters regarding the UI and the most recent concern adding a
database for it. We figured it might be good to use the core db only for the
"standard" UI with which we'll communicate through the rest-client and for
organizations wishing to customize the UI, such as Systers, we'll let them
add a UI db.
Other things we've discussed was the number of apps for the UI, if we should
use only one or if we should separate it into, for instance, one app for the
user UI's and one for the admin UI, or possibly split it up even more.
We've gathered all our thoughts on
http://wiki.list.org/display/DEV/Web+Interface+Status and now we'd like to
get some feedback from you people as well as to find out if you have other
opinions or ideas for us. I/we would really appreciate your help on this.



I hope that you plan on following WCAG 2.0 standards!  There are 
plenty of moderators and Admins who are blind or have other 
disabilities and still want to keep using the software!


Dave


___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Geoff Shang]

On Fri, 4 Jun 2010, Anna Granudd wrote:


there are some mock-ups on the wiki (see
http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you
could help with ideas for a nice design and layout!


As a blind person, I'm not able to comment on these as these are images.

I can understand the desire for an overhall of the Mailman UI, but I think 
it's worth saying that for the most part, the 2.x UI works well for people 
using screen reader technology.  The only area which provides some 
challenges is the membership management screen, as it can be difficult to 
associate each checkbox with the function it performs.  But even this can 
be managed using screen reader commands for reading tables.


I realise that Mailman 3.x will make it possible to create multiple UIs, 
as the functionality will be separated from the UI.  However, it is also 
my experience that alternate/specialised UIs can and do go unmaintained, 
and as such it is my hope that the (or at least a) standard UI shipped by 
default with Mailman will provide the needed accessibility.


So this is one of the reasons why I'm on this list, to keep an eye on 
developments and hopefully provide some feedback when a test server 
becomes available.


Right now, my UI wishlist is as follows:

1.  At least one UI with no *necessary* javascript. Maybe this won't be 
the main UI, but as a person who uses the Linux console with a text-mode 
browser, I like the fact that I can quickly fire up my browser to deal 
with a moderator request with no fuss.  Given that a package like 
Squirrelmail can operate completely without Javascript if the user 
chooses, this should surely be possible.


2.  Proper use of the label tag in association with form elements.  This 
was (or seemed to be done) fairly well for the most part, with the 
exception of those checkboxes I mentioned, but I'd hate to see this lost. 
What this means in practice is that screen readers will read the 
appropriate label text when focusing upon a form element.


There's probably other important stuff, but this is all that comes to mind 
right now.


Other non-accessibility-related things which I think are worth considering 
are:


1.  More useful archives with search capability.  I'm sure this is on a 
dozen wishlists.


2.  A friendlier front page per list.  Surely having 3 forms on the front 
page (or is it 4?) is a bit intimidating to some.


I've got some other feature requests based on 2.1.x functionality but I'll 
post that somewhere else more appropriate.


Geoff.

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 04, 2010, at 10:01 AM, Mark Sapiro wrote:

>Adam McGreggor wrote:
>
>>On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote:
>>> 
>>> Is it?  Aren't most open source discussion lists generally open membership
>>> (perhaps with initial moderation)?
>>
>>I'm not quite sure I go as far as
>>Ian, in requiring approval, but certainly to require confirmation, and
>>I might suggest, moderation bit being set, too. 
>
>
>I think that's exactly what Barry was saying. "open membership" does
>not imply subscription without confirmation. It only means
>subscription without approval.

Correct.
-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Mark Sapiro]

Adam McGreggor wrote:

>On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote:
>> 
>> Is it?  Aren't most open source discussion lists generally open membership
>> (perhaps with initial moderation)?
>
>I'm not quite sure I go as far as
>Ian, in requiring approval, but certainly to require confirmation, and
>I might suggest, moderation bit being set, too. 


I think that's exactly what Barry was saying. "open membership" does
not imply subscription without confirmation. It only means
subscription without approval.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Mark Sapiro]

Ian Eiloart wrote:
>
>--On 4 June 2010 11:12:04 -0400 Barry Warsaw  wrote:
>
>> Is it?  Aren't most open source discussion lists generally open membership
>> (perhaps with initial moderation)?
>
>Well, maybe, but I've had to switch on approval for various lists because 
>of subscribing spammers.


As Barry suggests, setting moderation of new members as the default can
also thwart the subscribing spammers.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Ian Eiloart]

--On 4 June 2010 11:12:04 -0400 Barry Warsaw  wrote:


On Jun 04, 2010, at 11:20 AM, Ian Eiloart wrote:


   2. Admin ability to create/delete lists via pre-defined styles


Note that in my current thinking, it is the site admin who can create
styles.


Right, but it would be nice if Mailman came with some styles out of the
box. At least, a "closed discussion list" and an "announcement list".


Yes, Mailman will definitely come with a few built-in styles.


These days, I guess that requiring approval for membership should be the
default, so that should be part of any shipping style.


Is it?  Aren't most open source discussion lists generally open membership
(perhaps with initial moderation)?


Well, maybe, but I've had to switch on approval for various lists because 
of subscribing spammers.



-Barry





--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Adam McGreggor]

On Fri, Jun 04, 2010 at 11:12:04AM -0400, Barry Warsaw wrote:
> On Jun 04, 2010, at 11:20 AM, Ian Eiloart wrote:
> >These days, I guess that requiring approval for membership should be the 
> >default, so that should be part of any shipping style.
> 
> Is it?  Aren't most open source discussion lists generally open membership
> (perhaps with initial moderation)?

Are we (as a community) forgetting who the majority of users/admins
who need "more help than normal" are?

I would have thought more "real-world" users of Mailman, would be the
sort of things we see questions being asked about on mailman-users;
newsletters, announcement lists, that sort of thing, rather than what
we, as geeks are au fait with.

I'm more of the mould that maybe we should make things a little easier
for those who can't read source-code, who need something up and
running quickly and without fuss; I'm not quite sure I go as far as
Ian, in requiring approval, but certainly to require confirmation, and
I might suggest, moderation bit being set, too. 

(most of *my* 400 odd lists are for non-geeks; a majority of them
are open-subscription, without moderation, but I vaguely keep an eye
on the amounts of mail going to each list; there's an element of
trust, and vigorous spam-filtering going on before mail gets to
Mailman). 


-- 
If we couldn't laugh at things that didn't make sense,
we couldn't react to a lot of the world around us. (Calvin and Hobbes)
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 04, 2010, at 11:20 AM, Ian Eiloart wrote:

>>>2. Admin ability to create/delete lists via pre-defined styles
>>
>> Note that in my current thinking, it is the site admin who can create
>> styles.
>
>Right, but it would be nice if Mailman came with some styles out of the 
>box. At least, a "closed discussion list" and an "announcement list".

Yes, Mailman will definitely come with a few built-in styles.

>These days, I guess that requiring approval for membership should be the 
>default, so that should be part of any shipping style.

Is it?  Aren't most open source discussion lists generally open membership
(perhaps with initial moderation)?

-Barry



signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 04, 2010, at 10:02 AM, Anna Granudd wrote:

>there are some mock-ups on the wiki (see
>http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you
>could help with ideas for a nice design and layout!

Martin's a rock star, so I'm sure he'll come up with some really nice
stuff.  Go Beuno!  :)

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 03, 2010, at 04:37 PM, Richard Leland wrote:

>Django's handling of i18n/l10n is well done. You could also use something
>like Transifex to encourage contributions in various langs.
>
>http://docs.djangoproject.com/en/1.2/topics/i18n/#topics-i18n
>http://www.transifex.net/

We'll probably end up using Launchpad since our branches and bug trackers are
there, but Transifex does look nice.

-Barry


signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Martin Albisetti]

On Thu, Jun 3, 2010 at 2:29 PM, Anna Granudd  wrote:
> my name is Anna and I'm participating in GSoC for Systers where my project
> this summer is to develop a new UI for Mailman 3.0 as well as a UI extension
> for Systers who are running a customized version of Mailman.

Hi Anna!

It's great to see this happening.
Do you have a clear idea and/or wireframes for the layouts of the pages?

If not, I'd be happy to help mock-up a default "skin" that looks nice
and easy to use.


-- 
Martin
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Ian Eiloart]

--On 3 June 2010 14:20:25 -0400 Barry Warsaw  wrote:


   2. Admin ability to create/delete lists via pre-defined styles


Note that in my current thinking, it is the site admin who can create
styles.


Right, but it would be nice if Mailman came with some styles out of the 
box. At least, a "closed discussion list" and an "announcement list".


These days, I guess that requiring approval for membership should be the 
default, so that should be part of any shipping style.


--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/


___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Anna Granudd]

Hi,
there are some mock-ups on the wiki (see
http://wiki.list.org/display/DEV/Web+UI+Mockups) but it'd be great if you
could help with ideas for a nice design and layout!

Thanks,
Anna

On Fri, Jun 4, 2010 at 9:05 AM, Martin Albisetti wrote:

> Hi Anna!
>
> It's great to see this happening.
> Do you have a clear idea and/or wireframes for the layouts of the pages?
>
> If not, I'd be happy to help mock-up a default "skin" that looks nice
> and easy to use.
>
>
> --
> Martin
>
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Richard Leland]

Django's handling of i18n/l10n is well done. You could also use something
like Transifex to encourage contributions in various langs.

http://docs.djangoproject.com/en/1.2/topics/i18n/#topics-i18n
http://www.transifex.net/

Richard Leland
r...@richleland.com
240-242-7424


On Thu, Jun 3, 2010 at 2:20 PM, Barry Warsaw  wrote:

> On Jun 03, 2010, at 04:56 PM, Adam McGreggor wrote:
>
> >I think I may be missing something: "Systers". Is this something
> >specific?
>
> www.systers.org
>
> >> The UI will be
> >> written as an app in Django. Together with my mentor Florian we've
> discussed
> >> some general matters regarding the UI and the most recent concern adding
> a
> >> database for it. We figured it might be good to use the core db only for
> the
> >> "standard" UI with which we'll communicate through the rest-client and
> for
> >> organizations wishing to customize the UI, such as Systers, we'll let
> them
> >> add a UI db.
> >
> >Do translations/i18n aspects come under UI customizations?
>
> We do eventually need to make sure all of the web ui can be translated.
> Ideally, we'd be able to extract text strings into .pot files and then set
> up
> a catalog for the wui.  I don't know how Django does it, but it should be
> part
> of the story.
>
> >1. Ability for users to subscribe, manage subscriptions,
> >   unsubscribe, change emails
> >2. Admin ability to create/delete lists via pre-defined styles
>
> Note that in my current thinking, it is the site admin who can create
> styles.
> I don't know if individual list admins should be able to do that, though
> they
> should definitely be able to pick a style and do some customizations of
> their
> list.  The ability of site admins to lock down styles, control
> customizations,
> and delegate style definitions can come later.
>
> >3. Users ability to customize their subscirptions
> >
> >s/subscirptions/subscriptions/
> >
> >4. Moderation
> >5. Site admin ability to create domains, add and modify
> >   styles
> >6. List admin ability to customize lists
> >
> >I think admins being able to set-up/customize lists, is probably
> >equally important, if not more important, then being able to
> >(un)sub; if the lists can't easily be set-up, then what's the point in
> >having people subscribe to them?
>
> Lists can currently be easily created on the command line, and
> subbing/unsubbing is a much more common task, so I think there is an
> argument
> for users being able to easily join/leave existing lists before it's easy
> to
> create lists through the web.  But I don't have strong feelings either way.
>
> -Barry
>
>
> ___
> 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/rich%40richleland.com
>
> Security Policy: http://wiki.list.org/x/QIA9
>
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Barry Warsaw]

On Jun 03, 2010, at 04:56 PM, Adam McGreggor wrote:

>I think I may be missing something: "Systers". Is this something
>specific?

www.systers.org

>> The UI will be
>> written as an app in Django. Together with my mentor Florian we've discussed
>> some general matters regarding the UI and the most recent concern adding a
>> database for it. We figured it might be good to use the core db only for the
>> "standard" UI with which we'll communicate through the rest-client and for
>> organizations wishing to customize the UI, such as Systers, we'll let them
>> add a UI db.
>
>Do translations/i18n aspects come under UI customizations?

We do eventually need to make sure all of the web ui can be translated.
Ideally, we'd be able to extract text strings into .pot files and then set up
a catalog for the wui.  I don't know how Django does it, but it should be part
of the story.

>1. Ability for users to subscribe, manage subscriptions,
>   unsubscribe, change emails
>2. Admin ability to create/delete lists via pre-defined styles

Note that in my current thinking, it is the site admin who can create styles.
I don't know if individual list admins should be able to do that, though they
should definitely be able to pick a style and do some customizations of their
list.  The ability of site admins to lock down styles, control customizations,
and delegate style definitions can come later.

>3. Users ability to customize their subscirptions
>
>s/subscirptions/subscriptions/
>
>4. Moderation
>5. Site admin ability to create domains, add and modify
>   styles
>6. List admin ability to customize lists
>
>I think admins being able to set-up/customize lists, is probably
>equally important, if not more important, then being able to
>(un)sub; if the lists can't easily be set-up, then what's the point in
>having people subscribe to them?

Lists can currently be easily created on the command line, and
subbing/unsubbing is a much more common task, so I think there is an argument
for users being able to easily join/leave existing lists before it's easy to
create lists through the web.  But I don't have strong feelings either way.

-Barry



signature.asc
Description: PGP signature
___
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

Re: [Mailman-Developers] UI for Mailman 3.0 update

[Adam McGreggor]

hey,

On Thu, Jun 03, 2010 at 02:29:40PM +0200, Anna Granudd wrote:
> my name is Anna and I'm participating in GSoC for Systers where my project
> this summer is to develop a new UI for Mailman 3.0 as well as a UI extension
> for Systers who are running a customized version of Mailman. 

I think I may be missing something: "Systers". Is this something
specific?

> The UI will be
> written as an app in Django. Together with my mentor Florian we've discussed
> some general matters regarding the UI and the most recent concern adding a
> database for it. We figured it might be good to use the core db only for the
> "standard" UI with which we'll communicate through the rest-client and for
> organizations wishing to customize the UI, such as Systers, we'll let them
> add a UI db.

Do translations/i18n aspects come under UI customizations?

> Other things we've discussed was the number of apps for the UI, if we should
> use only one or if we should separate it into, for instance, one app for the
> user UI's and one for the admin UI, or possibly split it up even more.
> We've gathered all our thoughts on
> http://wiki.list.org/display/DEV/Web+Interface+Status and now we'd like to
> get some feedback from you people as well as to find out if you have other
> opinions or ideas for us. I/we would really appreciate your help on this.

In "Features to be implemented first"

1. Ability for users to subscribe, manage subscriptions,
   unsubscribe, change emails
2. Admin ability to create/delete lists via pre-defined styles
3. Users ability to customize their subscirptions

s/subscirptions/subscriptions/

4. Moderation
5. Site admin ability to create domains, add and modify
   styles
6. List admin ability to customize lists

I think admins being able to set-up/customize lists, is probably
equally important, if not more important, then being able to
(un)sub; if the lists can't easily be set-up, then what's the point in
having people subscribe to them?

a

-- 
``Freedom of the press in Britain means freedom to print such of the
  proprietor's prejudices as the advertisers don't object to.''
  (Hannen Swaffer)
___
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