*** pojadhav is now known as pojadhav|afk | 07:31 | |
*** pojadhav|afk is now known as pojadhav\ | 08:26 | |
*** pojadhav\ is now known as pojadhav | 08:26 | |
*** tkajinam is now known as tkajinam|away | 08:33 | |
*** pojadhav- is now known as pojadhav | 14:06 | |
*** pojadhav- is now known as pojadhav | 14:22 | |
*** tkajinam|away is now known as tkajinam | 14:42 | |
ildikov | gmann: hi! I wanted to quickly ping you about the CFN initiative that folks from China Mobile started to discuss on the ML | 17:22 |
---|---|---|
ildikov | gmann: A few of us from the OpenInfra Foundation started to work with the group to understand the proposal better. From what we can see for now is that it has a much wider scope than a SIG in OpenStack. | 17:23 |
gmann | ildikov: yeah, I pinged tc-members to look into that and reply ^^. Also I will it in tc meeting agenda for Thursday and discuss about it. | 17:23 |
gmann | ildikov: ohk, are you discussing on ML? | 17:23 |
ildikov | gmann: We discussed it separately with them as it looks like it would be better as an initiative outside of OpenStack. | 17:24 |
ildikov | gmann: I can also drop a quick note to the thread on openstack-discuss as well if that helps | 17:25 |
gmann | ildikov: yes, please. it will help us if we can discuss it on ML. may be detail discussion you had with them not just quick note :) | 17:26 |
ildikov | gmann: we don't have a full consensus yet, but I will highlight the relevant thoughts | 17:27 |
gmann | ildikov: yeah i mean not consensus but the point you discussed and points for adding it outside of openstack | 17:28 |
ildikov | gmann: yep, that's what I meant by relevant items | 17:29 |
gmann | ildikov: cool, thanks. | 17:29 |
ildikov | gmann: happy to help! | 17:30 |
gmann | replied there to ask few more details. | 17:51 |
gmann | seems my reply to openstack-discuss ML thread is not through, complaining about "Too many recipients to the message" - http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028174.html | 18:26 |
gmann | may be we should relax this rule ^^ on ML. | 18:27 |
gmann | fungi: ^^ | 18:27 |
clarkb | gmann: I think the idea behind that rule is if you are using a mailing list you don't need a ton of recipients. Instead you send it to the list for it to distribute | 18:27 |
clarkb | so its a sanity check | 18:27 |
gmann | yeah if all recipients have joined the ML but it is not necessary to have that case always for example case like CFN proposal where many other non openstack members might be interested to participate in that particular thread | 18:29 |
gmann | anyways it is stuck on list moderator to approve that reply now. which I think fungi ? | 18:30 |
clarkb | is fungi moderates that list | 18:30 |
clarkb | s/is/yes/ | 18:30 |
gmann | ok, let's wait for him to approve. | 18:30 |
fungi | yeah, i try to check the moderation queue at least once a day, but i'll pull it up again in a few minutes | 18:55 |
fungi | and the "too many recipients" rule is there for a few reasons: 1. to stop people from crazily cross-posting to a bunch of mailing lists with a single message, 2. to minimize "group reply" from lots of recipients who aren't list subscribers, and 3. to reduce duplicate messages going to people who are subscribed but also unnecessarily included in the poster's cc header | 18:56 |
fungi | i always try to remove all recipients from my posts/replies except the list, unless i know that i need to also send a copy to a specific person who isn't subscribed (and even then i'm more likely to send a separate message to them linking to the list archive of my response and suggesting that they subscribe to the ml in order to receive further updates) | 18:58 |
gmann | I understand the reason for this check but like in CFN case, it seems a valid list of recipients from 99cloud, intel, chinamobile who are just participating in this thread and do not want to subscribed to ML and get all other emails | 19:03 |
gmann | I think we can relax this check little bit. | 19:04 |
gmann | otherwise I am not sure how many reply will be there, you end up approving all those. | 19:04 |
gmann | it seems 10 recipients in this example it is blocked. | 19:05 |
fungi | yes, almost none of them (pretty much only the original poster) has sent anything to the list anyway | 19:05 |
gmann | If anyone from community will reply to all then it stuck again. | 19:06 |
fungi | on average i approve one or two posts a week out of the moderation queue because they've been stuck with that check. the vast majority of the posts i end up having to approve are from people who didn't subscribe but still sent something to the list address | 19:06 |
gmann | if we really want to keep this check then may be to extend the threshold to 20-30 etc? | 19:07 |
fungi | why? | 19:07 |
gmann | yeah, anyone not subscribed and want to reply it make sense to ask them subscribe | 19:07 |
fungi | it wouldn't create any significant reduction in the moderation workload | 19:07 |
gmann | because everyone from community rely to all to this 10 recipients list will need approval | 19:08 |
gmann | reply | 19:08 |
fungi | most of the work for the moderators is wading through the hundreds of spam messages per day which go to the list address. a handful of replies which are stuck because of one of the various safety checks (too many recipients, message too large, et cetera) doesn't really have that much impact | 19:09 |
fungi | sometimes those posts don't make it to the list for up to a day, but it's not the end of the world | 19:09 |
fungi | and if we had more active moderators for the ml, it would be no more than a few hours (or even minutes) on average | 19:10 |
fungi | the "too many recipients" response also serves as a reminder to posters to delete their message from the queue and try again after trimming unnecessary recipients, or to do a better job of reducing the size of the included recipients in future messages | 19:14 |
gmann | I am not sure that is valid thing to do in ML as we might not know who to trim. like this case, I cannot or should not remove people from the original list | 19:15 |
gmann | I feel this is too restrictive check about "you can reply on ML with ~10 recipients " | 19:16 |
gmann | *"you can not reply on ML with ~10 recipients " | 19:16 |
fungi | i remove all recipients, on the implicit assumption that if they want to see replies they'll subscribe to the mailing list or check the archive, but maybe that's just me | 19:17 |
fungi | i also often set reply-to and mail-followup-to as the list when i reply, if i'm particularly concerned they might reply to me directly | 19:19 |
fungi | that is, if i do keep any of the original recipients in a reply | 19:19 |
gmann | expecting that form new people like this proposal is not that good. and that happen with new people to community only. existing one are already in ML subscription. | 19:20 |
gmann | they learn slowly and we should give them time instead of removing them from email reply they are part of. | 19:21 |
fungi | anyway, messages with lots of random people in cc are not really what discussion mailing lists are designed for, so as the currently most active list moderator i'm strongly in favor of keeping the "too many recipients" check as a reminder to posters when they try to apply the mailing list in problematic ways | 19:22 |
gmann | they are not random, I think that are valid recipients for the very new proposal to community. | 19:22 |
fungi | same thing with holding messages for moderation if they're from someone who isn't subscribed (which is the vast majority of the held messages, and catches about 100% of the spam too) | 19:23 |
fungi | for the record, the person posting that proposal was not a list subscriber anyway | 19:23 |
gmann | yeah they are very new to openstack | 19:24 |
gmann | anyways that is my opinion. I still feel "10 recipients" in the ML check is too restrictive. | 19:24 |
fungi | i suspect they don't actually know the difference between the openstack project and the open infrastructure foundation, and think that sigs in openstack are like sigs in kubernetes | 19:24 |
fungi | which is why i encouraged the foundation staff to connect with them and try to help educate them immediately after they sent that initial proposal | 19:25 |
fungi | and based on those discussions it seems like they didn't actually want what an openstack sig is, but they're also too disconnected from the current community to know that they should respond to their initial proposal retracting it so that the openstack tc doesn't spend a lot of time on it without realizing it's using our terminology in ways which don't match our governance model | 19:27 |
gmann | that's what we can clarify them in ML and but we are restrictive on ML reply | 19:28 |
gmann | author of email reached out to me on brining this in TC and reply on ML | 19:29 |
fungi | yes, given the prevailing cultural norms in their region of the world, i was hoping to save them the public embarrassment | 19:30 |
gmann | "0public embarrassment" ? | 19:30 |
gmann | "public embarrassment" ? | 19:30 |
fungi | for proposing to create a sig in openstack when they're describing something which wouldn't really take place in openstack | 19:31 |
fungi | anyway, it's moot now | 19:32 |
gmann | asking those question or trying to understand community, is not *public embarrassment* | 19:32 |
gmann | and that is what discussion in community is to decide where their proposal fit in. | 19:33 |
fungi | yes, it's proceeding in that direction now. i guess we'll see how they respond | 19:33 |
gmann | or TC or community discuss and update them and extract if few things can be helpful in OpenStack | 19:33 |
gmann | hoping, people reply to that thread does not get frustrated with email rejection. let's see | 19:34 |
fungi | their messages get held for moderation anyway because none of them are subscribers | 19:36 |
gmann | i mean tc or community members reply. | 19:37 |
fungi | if the proposal to create a sig in openstack is genuine, they're going to need to learn to pay attention to the openstack discussion mailing list anyway, so replies don't need to separately cc them | 19:40 |
gmann | ok, we are asking "you want to learn the community ? you need to know community first" | 19:42 |
gmann | providing extra help/relaxation in process/rules to new people does not harm much | 19:42 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!