creation of a list shouldn't need pre-approval
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Barry Warsaw |
Bug Description
There doesn't seem to be a good reason to have pre-approval before creating a mailing list: subscribers need to opt-in themselves so they can't really be a spam vector. Adding a separate approval phase causes handoffs for users.
See thread "Why do lists need special approval?"
---
To follow on from the recent 'why approve projects' discussion:
Ian just created a mailing list team for Windows users of Bazaar -
<https:/
wanted to announce it to the community and invite people to join, but
it kind of deflates the announcement to say 'at some time in the
future you'll be able to join a list' and the distinction between
being on the team but not on the list may be confusing.
I see in https:/
> The Launchpad team reviews all new requests for mailing lists. This is to help reduce misuse of the Launchpad's list hosting.
> You can request a mailing list for your team by clicking Configure mailing list on the team's overview page.
> We handle new mailing list application requests several times a day and will enable your mailing list as soon as possible. Once we've approved your mailing list, you'll see a Configure mailing list on your team's overview page.
So maybe he wouldn't have had to wait too long.
On the other hand, since people apparently have to opt in to join a
list, does this really reduce misuse?
----
No, only the user can subscribe himself via the web ui (we can of course do it behind the scenes with a script, and occasionally do when migrating a mailing list). So I think the spam argument isn't particularly relevant.
-Barry
-----
What if we
a) Put a big notice there reminding people to create Ubuntu lists at
lists.
b) If a list has ubuntu in its name, interpose a warning+
screen, and
c) For the few mistakes that still happen, just do post-facto review
and move them over to ubuntu.com as needed.
?
> * Reduce spam — I am not sure how spam is possible otherwise (can list
> owner subscribe people without them wanting to be on the list?), and we
> can probably stop worrying about this one
(Spam appears not to be an issue, as per later mails in this thread.)
> In general, any mailing list request should not wait for more than 1
> working day as is right now.
The difference between "instantaneous" and "any delay at all" is
infinite, and is a real problem. When someone is doing a multi-part
task, if we introduce a delay to *any* part, we've effectively stopped
the task until that person next gets time to work on it.
This makes Launchpad unfriendly to opportunistic collaboration. And
since the task itself might be part of some larger group activity, these
delays can cascade through the system, affecting many people.
As much as possible, Launchpad should do what the user requested the
instant the user requested it -- we can clean up the mistakes later in
most cases.
So, prioritizing a "no delay" philosophy: can we let users create
mailing lists directly? I think so. A clear notice should stop most of
them; a warning screen will catch most of the rest; and we can clean up
the mistakes. This would be a big improvement in user experience.
(And for the future: do we have any general policy on adding new
approval-requiring features to Launchpad? Like "Don't do that"? :-) )
-Karl
Related branches
- Curtis Hovey (community): Approve (code)
-
Diff: 2423 lines (+319/-1023)25 files modifiedlib/canonical/launchpad/browser/launchpad.py (+0/-2)
lib/canonical/launchpad/configure.zcml (+0/-6)
lib/canonical/launchpad/doc/canonical_url_examples.txt (+0/-6)
lib/lp/registry/browser/tests/mailinglist-views.txt (+5/-4)
lib/lp/registry/doc/mailinglist-xmlrpc.txt (+36/-69)
lib/lp/registry/doc/mailinglists.txt (+137/-331)
lib/lp/registry/doc/person-merge.txt (+6/-2)
lib/lp/registry/doc/vocabularies.txt (+0/-12)
lib/lp/registry/interfaces/mailinglist.py (+10/-37)
lib/lp/registry/model/mailinglist.py (+14/-34)
lib/lp/registry/stories/mailinglists/admin-approval.txt (+0/-221)
lib/lp/registry/stories/mailinglists/lifecycle.txt (+39/-110)
lib/lp/registry/stories/mailinglists/moderation.txt (+3/-5)
lib/lp/registry/stories/mailinglists/subscriptions.txt (+22/-26)
lib/lp/registry/stories/person/xx-user-to-user.txt (+11/-8)
lib/lp/registry/stories/team/xx-team-edit.txt (+0/-1)
lib/lp/registry/templates/team-mailinglist.pt (+4/-0)
lib/lp/registry/tests/mailinglists_helper.py (+1/-41)
lib/lp/registry/tests/test_person.py (+9/-0)
lib/lp/services/mailman/doc/contact-address.txt (+2/-2)
lib/lp/services/mailman/doc/create-lists.txt (+11/-48)
lib/lp/services/mailman/doc/modify-lists.txt (+7/-47)
lib/lp/services/mailman/doc/staging.txt (+2/-2)
lib/lp/services/mailman/testing/helpers.py (+0/-4)
lib/lp/testing/factory.py (+0/-5)
affects: | launchpad-foundations → launchpad-registry |
Changed in launchpad-registry: | |
importance: | Undecided → Low |
status: | New → Triaged |
tags: | added: mailing-lists |
tags: | added: gatekeeper |
Changed in launchpad-registry: | |
importance: | Low → High |
assignee: | nobody → Barry Warsaw (barry) |
milestone: | none → 3.1.12 |
Changed in launchpad-registry: | |
status: | Triaged → In Progress |
Changed in launchpad-registry: | |
status: | In Progress → Fix Committed |
Changed in launchpad-registry: | |
status: | Fix Committed → Fix Released |
I have been waiting a few hours for a mailing list to be approved. It isn't a good user experience. I have been occasionally active on launchpad for over a year now so it is probably safe to assume that I won't use the new list for spam.