<div dir="ltr">Thanks Clint!<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 2:41 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Shamail Tahir's message of 2017-02-27 00:44:44 -0500:<br>
<div><div class="h5">> Hi Clint,<br>
><br>
> On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
><br>
> > Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600:<br>
> > > On 2/26/2017 6:52 PM, Clint Byrum wrote:<br>
> > > > During some productive discussions in the Stewardship Working Group PTG<br>
> > > > room, the subject of the mailing list came up. The usual questions<br>
> > > > around whether or not we should have per-project lists came up and the<br>
> > > > reasons we don't were re-affirmed. To recap those reasons:<br>
> > > ><br>
> > > >   * Cross posting is the pits<br>
> > > >   * People don't always know at the beginning of a thread that a<br>
> > > >     discussion will need to go wider, leading to silos and confusion.<br>
> > > ><br>
> > > > So we turned to ways to help reduce peoples' load while reading e-mail,<br>
> > > > since many (most?) tend to opt out of reading openstack-dev.<br>
> > > ><br>
> > > > There are a number of ways that we can help, including teaching people<br>
> > > > to have more efficient workflows and use specific mail reading tools<br>
> > > > (don't worry, we're not adding an NNTP gateway.. yet). But one that<br>
> > > > received positive feedback from the room was to have moderated<br>
> > > > business-only mailing lists for each project.<br>
> > > ><br>
> > > > Basically, there are things that we _do_ know will not go wider when<br>
> > > > the thread begins. Just running through the threads on the February<br>
> > > > thread index, there are a few obvious classes:<br>
> > > ><br>
> > > >   * Mascots<br>
> > > >   * Social meetups<br>
> > > >   * Meeting logistics<br>
> > > >   * Core team membership<br>
> > > ><br>
> ><br>
> I'm curious as to how much of the traffic (such as the examples given)<br>
> generates message fatigue on new users but I do appreciate that we are<br>
> trying to find solutions to make it easier to enter into the mailing lists<br>
> around OpenStack without having to resort to digests.<br>
><br>
<br>
</div></div>I think it's worth analyzing it, if somebody has time. I do not. My wild<br>
ass guess is between 1 and 5 percent of all messages, but probably more<br>
like 5-10 percent of threads, as a lot of them are the shorter, less<br>
interesting threads.<br>
<br>
These seem like small numbers, but cognitive load is not linear and the<br>
number of threads people end up reading varies whether or not they use<br>
tags.<br></blockquote><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > > There are likely others. The idea is that these messages would go into a<br>
> > > > ${<a href="mailto:project%7D-business@lists.openstack.org">project}-business@lists.<wbr>openstack.org</a>. Said list would be moderated<br>
> > by<br>
> > > > a team of the PTL's choosing, and we would admonish moderators to<br>
> > reject<br>
> > > > soundly any threads not obviously single project business related.<br>
> ><br>
> In this approach, we could send messages that fall within the ${<br>
> <a href="mailto:project%7D-business@lists.openstack.org">project}-business@lists.<wbr>openstack.org</a> to the dev ML as well.  This would<br>
> allow people who want only the ${project}-business news to get the content<br>
> without having to get all messages from the dev ML but at the same time<br>
> allow threads to be available to both subscribers (dev and<br>
> ${project}-business}.<br>
><br>
> I hope we still advocate for subscribing to the openstack-dev mailing list<br>
> even if a contributor is only starting with a single project (and not<br>
> interested in cross-project things) because it allows for people to see<br>
> conversations they might have expertise in or find a new project they want<br>
> to contribute to based on learning something new about it.<br>
><br>
<br>
</span>Wow, I must have failed in my wording ,sorry about that, because you<br>
got it 100% backwards. The idea is that everyone stays in openstack-dev<br>
for _all_ discussions (single-project as well). Only the most mundane<br>
but necessary emails go on per-project "business lists". So there would<br>
be zero point in ever subscribing to the business lists without also<br>
subscribing to openstack-dev, and likewise, republishing business lists<br>
to openstack-dev would defeat the entire point.<br></blockquote><div> </div><div>Makes sense!  Sorry if I missed the intent.  In this case, I am in agreement with the original approach as well... my (unfounded) concern was about what it would do to openstack-dev traffic.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small">Thanks,</div><div style="font-size:small">Shamail Tahir</div><div style="font-size:small">t: @ShamailXD</div><div style="font-size:small">tz: Eastern Time</div></div></div></div></div>
</div></div>