On Fri, Oct 25, 2013 at 11:41 PM, Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx> wrote:
> On Fri, Oct 25, 2013 at 10:41:12AM -0700, Adam Williamson wrote:
>> > mailman topics/keywords features to sort into meaningful sub-categories. I
>> > understand that hyperkitty will make this nice and easy, but it's also not
>> > really very hard just as email. Note that you can subscribe to just certain
>> > topics, if you are not interested in certain areas.
>> So, have fewer lists, but then have what are effectively sub-lists
>> within the lists. Where exactly is the win?
>
> Opting in / out of topics is more lightweight than subscribing and
> unsubscribing.
Subscribing to a mailing list is an one-time, <5-minute operation
(BTDT just today).
OTOH dealing with topics is a constant cost: mail programs have good
autocompletion for the To: field, but not for arbitrary syntax in
Subject:. It's mental overhead and there will be an unending stream
of mistakes.
> I'd love to hear better suggestions.... the main problem seems to be "it's
> so busy no one goes there anymore". How can we keep the discussion cohesive
> but prevent it from becoming overwhelming?
In general, avoid badly targeted email.
Doing this for human communication is fairly difficult - we'll see
whether/how much the new working groups will help minimizing the
communication that is irrelevant to most. (Corollary: if you care
about any of the WGs, subscribe now :) )
It would be probably simpler for the automated emails: unless everyone
on the list wants to, or should want to, read them, just stop sending
them; _and_, send them to a better targeted group, which would make
them more useful. E.g. the rawhide/F20 report and EVR problem e-mails
should, I think be sent to rel-eng (if they read it, that is) and the
packagers that need to take action. (Currently I never read them, so
I wouldn't even notice if they mentioned my package - for me they are
pure overhead.)
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
