# keeping traffic on this list manageable - Thread: https://externals.io/message/41593 - Original archive: https://news-web.php.net/php.internals/41593 - Started by Lukas Kahwe Smith on 2008-10-31T18:23:12+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/41593.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #41593 — Lukas Kahwe Smith — 2008-10-31T18:23:12+00:00 URL: https://externals.io/message/41593#41593 Hi, So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool. I had a chat about this with Zoe, Stephan (of symonfy fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it): What if we have two lists for internal discussions. One which is just as open as the current one and one that is moderated. People with commit karma for php-src (and maybe also phpdoc) get unmoderated access. However this obviously creates the issue that the community and newcomers will have a much harder time to get in contact with the core development team. As the list is moderated, it would require people to manually allow the given posts. This creates a bottleneck which would also create considerable work for those moderators. Here I come to the key part of my idea. We would allow every PHP usergroup to also appoint one person that gets unmoderated access to the list. This enables members of the usergroup to feed their ideas via that person directly to the list, taking load of the list moderators and ensuring that things a given UG deem important are not lost in this process. Furthermore this intermediate step would serve to throttle the traffic and make the numbers of posters (their writing style and expertise) more easily transparent to other posters (but more importantly to the readers). I am sure this will help reduce misunderstandings and more importantly result in a more friendly tone (its just natural for people to feel overwhelmed by too large a crowd). As a side bonus, we strengthen UGs around the world. This will hopefully lead to better communication channels between internals and active community members. It will certainly ease the organization of future testfests (or docfrenzy's) as we will then have contact people to talk to as well as more of an incentive for people to join their local UG. I would not want to try to come to a closed definition of what constitutes a UG. Lets just create an interface were people can register their UG and manage the email address for the contact person (and maybe a few other things like their website etc). People can create physical UGs as well as virtual UGs for all I care. If we notice that this liberal approach gets abused (people faking UGs to get direct access and more voting rights) we can decide on taking some protective measures. But for now lets just assume that everybody in the community understands the beauty of such a liberal approach. --- Just like in my previous email. Please all try to focus on sending high quality replies to this list. So lets all restrain ourselves and wait a bit longer than usual before replying. Maybe someone else will already make the point you want to make and in the mean time you can think things over and optimize your message. regards, Lukas Kahwe Smith mls@pooteeweet.org PS: I have published the above text as an RFC on the wiki .. http://wiki.php.net/rfc/managinglisttraffic --- ## #41594 — Steph Fox — 2008-10-31T18:33:53+00:00 URL: https://externals.io/message/41593#41594 · In reply to: #41593 Hi Lukas, > Here I come to the key part of my idea. We would allow every PHP > usergroup to also appoint one person that gets unmoderated access to the > list. Great idea! >Lets just create an interface were people can register their UG and manage >the email address for the contact person (and maybe a few other things >like their website etc). We have this already on php.net, no? >But for now lets just assume that everybody in the community understands >the beauty of such a liberal approach. There should be a similar scheme for teams that develop major PHP applications IMHO. Those developers are key. - Steph --- ## #41595 — Felix De Vliegher — 2008-10-31T18:53:26+00:00 URL: https://externals.io/message/41593#41595 · In reply to: #41593 Hi Lukas Sounds like a good idea to channel the volume on this list. I was wondering, would the usergroup part be a replacement for the moderated messages by regular users or would it be an addition to it? I mean, we should better start promoting this one moderator-per- usergroup to usergroups worldwide, because moderating regular users will still generate quite some additional work. Not all users who have ideas/questions worth asking are involved in a user group too. Anyhow, I'm up for an idea along these lines. Regards, Felix Op 31-okt-08, om 19:23 heeft Lukas Kahwe Smith het volgende geschreven: > Hi, > > So some core developers as well as lurking end users have noted that > the traffic on this list prevents them from being able to follow > this list. This is obviously a huge problem since this mailinglist > is supposed to be our primary discussion and decision making tool. > > I had a chat about this with Zoe, Stephan (of symonfy fame) and > Pierre at IPC. In this discussion I got the following idea (note > that I am listing the names here in order to credit them in this > idea, not because they necessarily endorse it): > > What if we have two lists for internal discussions. One which is > just as open as the current one and one that is moderated. People > with commit karma for php-src (and maybe also phpdoc) get > unmoderated access. However this obviously creates the issue that > the community and newcomers will have a much harder time to get in > contact with the core development team. As the list is moderated, it > would require people to manually allow the given posts. This creates > a bottleneck which would also create considerable work for those > moderators. > > Here I come to the key part of my idea. We would allow every PHP > usergroup to also appoint one person that gets unmoderated access to > the list. This enables members of the usergroup to feed their ideas > via that person directly to the list, taking load of the list > moderators and ensuring that things a given UG deem important are > not lost in this process. Furthermore this intermediate step would > serve to throttle the traffic and make the numbers of posters (their > writing style and expertise) more easily transparent to other > posters (but more importantly to the readers). I am sure this will > help reduce misunderstandings and more importantly result in a more > friendly tone (its just natural for people to feel overwhelmed by > too large a crowd). > > As a side bonus, we strengthen UGs around the world. This will > hopefully lead to better communication channels between internals > and active community members. It will certainly ease the > organization of future testfests (or docfrenzy's) as we will then > have contact people to talk to as well as more of an incentive for > people to join their local UG. I would not want to try to come to a > closed definition of what constitutes a UG. Lets just create an > interface were people can register their UG and manage the email > address for the contact person (and maybe a few other things like > their website etc). People can create physical UGs as well as > virtual UGs for all I care. If we notice that this liberal approach > gets abused (people faking UGs to get direct access and more voting > rights) we can decide on taking some protective measures. But for > now lets just assume that everybody in the community understands the > beauty of such a liberal approach. > > --- > > Just like in my previous email. Please all try to focus on sending > high quality replies to this list. So lets all restrain ourselves > and wait a bit longer than usual before replying. Maybe someone else > will already make the point you want to make and in the mean time > you can think things over and optimize your message. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > PS: I have published the above text as an RFC on the wiki .. http://wiki.php.net/rfc/managinglisttraffic --- ## #41596 — Rasmus Lerdorf — 2008-10-31T19:30:13+00:00 URL: https://externals.io/message/41593#41596 · In reply to: #41593 A simpler approach might be to just make the mailing list software enforce a 1 email per 24-hour day per user. It would require a bit more upfront work to munge the software, but wouldn't require any ongoing effort. Moderation can get messy since it isn't simply spam we or off-topic messages we are trying to control here, it is the volume, quality and timeliness of on-topic messages. I'm not sure moderation is the answer to that. We need a behavioural change here. -Rasmus --- ## #41597 — Stefan Walk — 2008-10-31T19:43:00+00:00 URL: https://externals.io/message/41593#41597 · In reply to: #41596 On Friday 31 October 2008 20:30:13 Rasmus Lerdorf wrote: > A simpler approach might be to just make the mailing list software > enforce a 1 email per 24-hour day per user. It would require a bit more > upfront work to munge the software, but wouldn't require any ongoing > effort. Moderation can get messy since it isn't simply spam we or > off-topic messages we are trying to control here, it is the volume, > quality and timeliness of on-topic messages. I'm not sure moderation is > the answer to that. We need a behavioural change here. > > -Rasmus Well, I don't think that won't work. There are cases where one user replied to multiple mails in a short time without fighting, just explaining and discussiong, and you don't want to block that - as well as it wouldn't stop random people from suggesting dropping the $ from variables, making the namespace separator configurable etc. IMO, it's the volume of people, not the volume of messages, that is the main problem here. Regards, Stefan --- ## #41598 — Hannes Magnusson — 2008-10-31T19:52:03+00:00 URL: https://externals.io/message/41593#41598 · In reply to: #41596 > A simpler approach might be to just make the mailing list software enforce a > 1 email per 24-hour day per user. It would require a bit more upfront work Thats not going to work, we often have multiple threads going on. Even if it was limited to one post per thread every 24hour people would simply create new threads about the same topic. Restricting the amount of mail is no solution, just causes annoyances. > to munge the software, but wouldn't require any ongoing effort. Moderation > can get messy since it isn't simply spam we or off-topic messages we are > trying to control here, it is the volume, quality and timeliness of on-topic > messages. I'm not sure moderation is the answer to that. We need a > behavioural change here. Behavioural change is desperately needed, and I think developers should lead by example. One way to to that is to add a new internal-core@ mailinglist which is read-only to the world, and writeable by people with appropriate karma. That list would be dedicated for _development_ discussion (including implementation, patches, "edge-case voting" and such things) and would include posts like are going on between greg, stas and dmitry, and posts which are going on between release managers and individual developers. This way we keep _everything_ in the open and maintain a "high quality" on-topic discussions. "external" patches and "general" discussions would still be on the internals@ list, as it would be the main discussion list. However, those who simply do not have the time to read over the entire thing have a specific low-traffic list which they can easily follow. For people not with "write privileges" they can still chime in by forwarding the posts to internals@ and give their 2cents. Another indirect advantage is when docwriters mail in asking what exactly something does, and if it really is meant to work that way, the thread is obviously coming from "internal" guy and therefore has a better chance of getting answers (rather then the "usual" ignore since apparently think he is just a troll). I cannot see any disadvantages here. I have faith in our developers. -Hannes --- ## #41599 — Rasmus Lerdorf — 2008-10-31T19:59:22+00:00 URL: https://externals.io/message/41593#41599 · In reply to: #41598 Hannes Magnusson wrote: > Behavioural change is desperately needed, and I think developers > should lead by example. > One way to to that is to add a new internal-core@ mailinglist which is > read-only to the world, and writeable by people with appropriate > karma. > > That list would be dedicated for _development_ discussion (including > implementation, patches, "edge-case voting" and such things) and would > include posts like are going on between greg, stas and dmitry, and > posts which are going on between release managers and individual > developers. This way we keep _everything_ in the open and maintain a > "high quality" on-topic discussions. > > "external" patches and "general" discussions would still be on the > internals@ list, as it would be the main discussion list. However, > those who simply do not have the time to read over the entire thing > have a specific low-traffic list which they can easily follow. This is the same as just making internals@ read-only. Once we have an internals-core, many core people will just unsubscribe from the internals list. I know I probably would. And once the core developers no longer read it, it becomes php-general2 and it ends up excluding people from the development process. -Rasmus --- ## #41601 — Hannes Magnusson — 2008-10-31T20:13:07+00:00 URL: https://externals.io/message/41593#41601 · In reply to: #41599 > Hannes Magnusson wrote: > > […] > > This is the same as just making internals@ read-only. Once we have an > internals-core, many core people will just unsubscribe from the internals > list. I know I probably would. And once the core developers no longer read > it, it becomes php-general2 and it ends up excluding people from the > development process. I have more faith in our devs then that. And I doubt you would unsubscribe, you care to much (and one of the few devs I've seen to reply to posts on php-general@ and then pear-dev@ the next day..). Most of us do. You would probably filter those posts into a different reading priority, but you would still browse through it. I expect bunch of silent listeners to unsubscribe from internals@ and subscribe to internals-core@ and I can even see some devs only subscribed to internals-core@ but I have no doubt that over 51% would stay stay subscribed to internals@ and would forward interesting discussions to internals-core@. -Hannes --- ## #41602 — Daniel Brown — 2008-10-31T20:13:41+00:00 URL: https://externals.io/message/41593#41602 · In reply to: #41599 > > This is the same as just making internals@ read-only. Once we have an > internals-core, many core people will just unsubscribe from the internals > list. I know I probably would. And once the core developers no longer read > it, it becomes php-general2 and it ends up excluding people from the > development process. I'd also be concerned about patch submissions. Would we leave that on internals@ still, or create yet another list, patches@? -- http://www.parasane.net/ daniel.brown@parasane.net || danbrown@php.net Ask me about our current hosting/dedicated server deals! --- ## #41603 — Hannes Magnusson — 2008-10-31T20:15:32+00:00 URL: https://externals.io/message/41593#41603 · In reply to: #41602 > > > […] > > I'd also be concerned about patch submissions. Would we leave > that on internals@ still, or create yet another list, patches@? Read the whole thread before posting please: > "external" patches and "general" discussions would still be on the > internals@ list, as it would be the main discussion list. -Hannes --- ## #41604 — Daniel Brown — 2008-10-31T20:17:49+00:00 URL: https://externals.io/message/41593#41604 · In reply to: #41603 On Fri, Oct 31, 2008 at 3:15 PM, Hannes Magnusson wrote: > > Read the whole thread before posting please: > > > […] I have been reading the entire thread, Hannes. I do not have any message that includes that quote. If you'd forward that message to me off-list, I'd be more than happy to read it. -- http://www.parasane.net/ daniel.brown@parasane.net || danbrown@php.net Ask me about our current hosting/dedicated server deals! --- ## #41605 — Jeremy — 2008-10-31T20:33:03+00:00 URL: https://externals.io/message/41593#41605 · In reply to: #41593 Lukas Kahwe Smith wrote: > Hi, > > So some core developers as well as lurking end users have noted that the > traffic on this list prevents them from being able to follow this list. > This is obviously a huge problem since this mailinglist is supposed to > be our primary discussion and decision making tool. > > Personally, I'm an end user who reads the list because I care about the direction PHP is taking. However, I have rarely had the need to post to any of the mailing lists. In any case, the traffic on the list is not a problem for me - because I access it through NNTP (news.php.net) and it never clogs my inbox. I personally think mailing lists are an awful way to maintain a set of many concurrent discussion threads, and NNTP is far superior. If you severely dislike receiving a lot of irrelevant e-mail, then maybe give news.php.net a try instead? That way, you can just browse the lists in a threaded view whenever you feel like it. Works well for me, anyway - but then, I'm not a PHP developer, so maybe the story is different. Jeremy --- ## #41606 — johannes@php.net — 2008-10-31T22:46:59+00:00 URL: https://externals.io/message/41593#41606 · In reply to: #41601 > > […] > > I have more faith in our devs then that. And I doubt you would > unsubscribe, you care to much (and one of the few devs I've seen to > reply to posts on php-general@ and then pear-dev@ the next day..). > Most of us do. You would probably filter those posts into a different > reading priority, but you would still browse through it. I assume some people would still be subscribed to it but just scroll over subjects from time to time with little interest, which might be frustrating to worthfull new contributors. Additionally I guess it would split discussions, so a "core" person proposes something to internals-readonly, then discussions happen on both lists with some cross-postings and some mails of a thread missing in one list - sounds annoying. johannes --- ## #41607 — Scott MacVicar — 2008-10-31T23:35:05+00:00 URL: https://externals.io/message/41593#41607 · In reply to: #41599 > Hannes Magnusson wrote: > > […] > > This is the same as just making internals@ read-only. Once we have > an internals-core, many core people will just unsubscribe from the > internals list. I know I probably would. And once the core > developers no longer read it, it becomes php-general2 and it ends up > excluding people from the development process. > Users can still use reply on the internals list, so the poster can still receive responses rather than relying on them being subscribed to the internals list. Scott --- ## #41608 — Hannes Magnusson — 2008-11-01T02:43:53+00:00 URL: https://externals.io/message/41593#41608 · In reply to: #41606 > > > […] [snip a good chunk of stuff] > Additionally I guess it would split discussions, so a "core" person > proposes something to internals-readonly, then discussions happen on > both lists with some cross-postings and some mails of a thread missing > in one list - sounds annoying. A '"core" person' is exactly the guy who I have faith in. If '"core" person' cannot respect the community he should be booted from php.net ASAP! A real core guy is subscribed to both list (probably with internals@ with slightly lower reading priority though). I don't give *********** what his/her name is, Sam Ruby, Andrei, Rasmus, Zeev (or any other "PHP Group" member), Johannes, Derick, Ilia (or any other "release master"), Jani, Tony, Zoy, Philip, Greg, Dmitry, Felipe, Melvyn Sopacua (have you heard that name before? checkout `phpcredits()`)........ I don't give a dmn what your name is. If you don't listen and respect the community you should be booted ASAP! I have a great deal of faith in the individual developer who actually cares. I have no faith in the enterprises or huge corporations who try to manipulate everything and everyone they touch. With a focused team we can do anything we want. With a team distracted of fuckedup politics and wtf "problems" we can't do anything. -Hannes --- ## #41609 — Ronald Chmara — 2008-11-01T06:19:32+00:00 URL: https://externals.io/message/41593#41609 · In reply to: #41597 > There are cases where one user replied to > multiple mails in a short time without fighting, just explaining and > discussiong, and you don't want to block that - as well as it > wouldn't stop > random people from suggesting dropping the $ from variables, making > the > namespace separator configurable etc. IMO, it's the volume of > people, not the > volume of messages, that is the main problem here. As a semi-non-random person (though people who have become very active only in the last few years may not remember me at all), I'd like to put in my two cents, based on, oh, 8+ years of working with this list, and my 22+ years of dealing with various lists/groups (email goes back to 1961, FWIW, before I was born). 1. Having a fairly advanced MUA helps. If you don't know what an MUA (Mail User Agent) is, then you may not remember the days when it was easy to get 1,800-10,000 messages a day off of various lists. The way this "message overload" problem was typically solved was with message grouping, and mail rules. Don't want to read a thread? Delete whole threads, not messages. Don't think a user is contributing? Put them in the bit-bucket. 2. Random off-topic-ness happens. It cannot be dictated away, moderated away, or programmed away. Feel free to try, but some of the best minds in the world have worked on this issue for 47 (yes, 47) years. No silver bullets, I'm afraid. 3. The "super-seekrit serious chat only about X" lists (or CC: chains, or IRC meetings, or wiki pages, or whatever) already exist, and have always existed. If people knew about them, they wouldn't be "seekrit", and away from the riff-raff of a publicly available mailing list. Most F/OSS projects have these back channels. They are not made available for public use because, well, they're not supposed to be. 4. If you are a developer of sufficient merit/need/value, you will likely be on both public lists for a project, and have access to the private back-channels for some things as well. This is just the way the system works. Sure, we could make official rules, and another shibboleth list/channel/chat/wiki, for a given piece of a project, and add another layer... but to what end? We already have a plethora of such channels, indeed, as a project grows, said channels create themselves out of necessity. So, to summarize, here's an example chain: -php-general -php-dev -, PHP sub-project "hidden/CC lists and chats" -, PHP core current C contributors and debuggers - Zeev (or who ever's) cell phone These layers already exist. The problem is not that we (as a community) lack these levels of discussion, the problem is that every so often, folks want to escalate to another level, or find that they've outgrown the level they're in, and complain about the 'Riff-Raff". If you contribute to higher levels, if you work on a feature that impacts others at a higher level, and want to also be a part of that smaller community, well..... it already exists. It just doesn't always have a mailing list that *anybody* can join because they "think they're important". -Bop --- ## #41610 — Larry Garfield — 2008-11-01T08:45:48+00:00 URL: https://externals.io/message/41593#41610 · In reply to: #41593 On Friday 31 October 2008 1:23:12 pm Lukas Kahwe Smith wrote: > Here I come to the key part of my idea. We would allow every PHP > usergroup to also appoint one person that gets unmoderated access to > the list. This enables members of the usergroup to feed their ideas > via that person directly to the list, taking load of the list > moderators and ensuring that things a given UG deem important are not > lost in this process. Furthermore this intermediate step would serve > to throttle the traffic and make the numbers of posters (their writing > style and expertise) more easily transparent to other posters (but > more importantly to the readers). I am sure this will help reduce > misunderstandings and more importantly result in a more friendly tone > (its just natural for people to feel overwhelmed by too large a crowd). My concern here is that an UG is not necessarily a good representative "constituency". As an example, I don't think there's anyone else from the Chicago UG on this list right now; certainly no one I recognize. Most of the local PHPers aren't interested in internals as far as I'm aware, for whatever reason. However, my main activity is with the Drupal project. More than half of the posts I make are related to how Drupal could potentially leverage new features down the road. If I were to "represent" any particular group and "ensure that things [it] deem[s] important", it would be Drupal, not Chicago, and I think I'm one of only 2 Drupal core devs on this list. But Drupal isn't an UG, so that wouldn't qualify as a constituency. I'm sure there's some other definition of constituency besides regional UG and project that makes just as much sense, too. From my mostly-outsider POV, most of the "noise" I see on this list is either bikeshedding (which is hardly a PHP-specific problem) or people that seem to know each other well so I assume are core folks talking past each other, whether maliciously or not. I don't see anything that "keep out the riff-raff" would inherently fix. Except for the recent namespace separator thread-of-doom, this list is generally much slower paced than, say, php-general. -- Larry Garfield larry@garfieldtech.com --- ## #41611 — johannes@php.net — 2008-11-01T13:34:50+00:00 URL: https://externals.io/message/41593#41611 · In reply to: #41607 > Users can still use reply on the internals list, so the poster can > still receive responses rather than relying on them being subscribed > to the internals list. So I see a mail in my inbox, then I'd have to check the internals folder scan through the mails there to see whether the poster was allowed to post there or not and if not forward the message? I doubt that happens. I expect the "core" guy reading the mail in his inbox will press "reply to all" and kick out some parts of the mail for not quoting the full mail. The "user" will miss his mail and forward it it to the public list. So on the "core" list you get a small part from the "user's" mail as a quote, the whole thing on the user's list ... which means the discussion gives two broken threads in two mailing lists. And even when it's forwarded threading would break which makes it hard to follow discussions. We'd have to make sure to use the "user's" list as regular discussion list and only put "important" stuff on the other list, but again I guess devs would use the more "comfortable" list more and more ... Anybody knows how other big projects are handling that? LKML for instance. Are people simply more afraid of sending stuff there or is there a smart way they use for moderation? johannes --- ## #41612 — Mike R — 2008-11-01T13:35:54+00:00 URL: https://externals.io/message/41593#41612 · In reply to: #41596 Rasmus Lerdorf wrote: > A simpler approach might be to just make the mailing list software > enforce a 1 email per 24-hour day per user. It would require a bit > more upfront work to munge the software, but wouldn't require any ongoing > effort. Moderation can get messy since it isn't simply spam we or > off-topic messages we are trying to control here, it is the volume, > quality and timeliness of on-topic messages. I'm not sure moderation > is the answer to that. We need a behavioural change here. IMHO,I don't think this approach would work, but moderation isn't the answer. PHP has far too vibrant a community to fall victim to this type of alienation. In the dozen+ years I've been subscribed I've never found the list so unmanageable as to warrant moderation of any kind. My eyeballs and the delete key are still pretty good BS filters. Behavioral change is exactly what is needed. The simplest way to achieve that is education and buy-in. A good start would be to document the desired behavior, in an isolated php-dev subscription page, in the form of a _brief_ terms of use, and have new subscribers acknowledge and agree to it. There could also be a cooling off period, where new subscribers are read-only for the first NN days - that'll let tempers and hair-triggers cool off. The core team is populated by some of the smartest people on the planet, I'm sure some other ideas can be bandied about and implemented to achieve the desired goal without resorting to moderation. Mike Robinson --- ## #41613 — Stefan Koopmanschap — 2008-11-01T15:11:04+00:00 URL: https://externals.io/message/41593#41613 · In reply to: #41593 Hi, While I have not been actively posting here yet, I would like to respond here (as my name got mentioned). Lukas Kahwe Smith wrote: > > I had a chat about this with Zoe, Stephan (of symonfy fame) and Pierre > at IPC. In this discussion I got the following idea (note that I am > listing the names here in order to credit them in this idea, not because > they necessarily endorse it): My name is Stefan Koopmanschap and I endorse this message ;) > > As a side bonus, we strengthen UGs around the world. This will hopefully > lead to better communication channels between internals and active > community members. It will certainly ease the organization of future > testfests (or docfrenzy's) as we will then have contact people to talk > to as well as more of an incentive for people to join their local UG. Being active in the Dutch usergroup, I am very much in support of this idea. Usergroups as they are now are too vague in their role within PHP. A lot of users that currently perhaps have great ideas for PHP would have a local point to talk to. Aside from code/functionality, they might also have an easier door towards contributing in terms of tests or documentation. It's a win/win situation, where the usergroup is able to more actively promote contributing to PHP itself as part of their more closely bound role in PHP, and the users of PHP have an easier way of giving feedback or offering their ideas. > I > would not want to try to come to a closed definition of what constitutes > a UG. Lets just create an interface were people can register their UG > and manage the email address for the contact person (and maybe a few > other things like their website etc). People can create physical UGs as > well as virtual UGs for all I care. If we notice that this liberal > approach gets abused (people faking UGs to get direct access and more > voting rights) we can decide on taking some protective measures. But for > now lets just assume that everybody in the community understands the > beauty of such a liberal approach. I am not so sure about this part though. Even though I am not someone who is usually for putting on this kind of limitations, the whole idea of this second list is to have a more closed environment for discussion. So taking some time to get to a clear definition (this could be a wide definition) would help make it easier. I do also think that not just usergroups but also the big projects (like Drupal as Larry mentioned) should have a place in this. Similar to usergroups, they could request access. As with usergroups, a certain (wide) definition of which projects would be granted access should be made. Given my above statement on limitations, I would even like to propose making the second list a completely closed list. If someone that is not on this closed list has an idea (s)he could post to internals@. If the idea is deemed good enough, a discussion on the closed list (internals-core@?) could be started about the issue. The person posing the idea could then (temporarily?) be added to the list to enable a clear discussion of the facts. In response to the question where patches should be sent to: I think they should initially be sent to internal@ where, similar as to the above idea, it could be picked up for discussion on the internals-core@ if need be. The only thing I currently do not have a clear solution for would be the distribution of a single discussion between the two lists. I do see that this might become problematic though. Obviously, people responding could reference to a http://news.php.net/ link to show what they are responding to, but this (c/w)ould become quite messy. My 2 cents, Stefan --- ## #41614 — Guilherme Blanco — 2008-11-01T17:17:54+00:00 URL: https://externals.io/message/41593#41614 · In reply to: #41613 Hi guys... The idea is awesome, but it'll definately not work. Sorry. By creating an UG profile subscription will allow again everyone to subscribe "a group" when it's really just one person that wants to write something. So the UG idea will not work. Now let's close the internals@. Again... it'll not work. Why? Let's suppose something. I'm a php user with read-only access with an interesting idea for php. I'd post to opened internals@. Then the subject start a no-human land discussion like the ns and it'll be moved to the closed internals@. And then the php user that gave the enlighting idea cannot write anything there... so... it'll not work. Ah... ok... give the php user write access.... but then it's another work for moderators. If it's ok for you... go ahead. Here are the reasons why I'm -1. My alternative is to simply kick users that start useless stuff. Ok, another task for moderators... but that's the only thing I could imagine. Regards, > Hi, > > While I have not been actively posting here yet, I would like to respond > here (as my name got mentioned). > > Lukas Kahwe Smith wrote: > > […] > > My name is Stefan Koopmanschap and I endorse this message ;) > > > […] > > Being active in the Dutch usergroup, I am very much in support of this idea. > Usergroups as they are now are too vague in their role within PHP. A lot of > users that currently perhaps have great ideas for PHP would have a local > point to talk to. Aside from code/functionality, they might also have an > easier door towards contributing in terms of tests or documentation. It's a > win/win situation, where the usergroup is able to more actively promote > contributing to PHP itself as part of their more closely bound role in PHP, > and the users of PHP have an easier way of giving feedback or offering their > ideas. > > > > […] > > I am not so sure about this part though. Even though I am not someone who is > usually for putting on this kind of limitations, the whole idea of this > second list is to have a more closed environment for discussion. So taking > some time to get to a clear definition (this could be a wide definition) > would help make it easier. > > I do also think that not just usergroups but also the big projects (like > Drupal as Larry mentioned) should have a place in this. Similar to > usergroups, they could request access. As with usergroups, a certain (wide) > definition of which projects would be granted access should be made. > > Given my above statement on limitations, I would even like to propose making > the second list a completely closed list. If someone that is not on this > closed list has an idea (s)he could post to internals@. If the idea is > deemed good enough, a discussion on the closed list (internals-core@?) could > be started about the issue. The person posing the idea could then > (temporarily?) be added to the list to enable a clear discussion of the > facts. > > In response to the question where patches should be sent to: I think they > should initially be sent to internal@ where, similar as to the above idea, > it could be picked up for discussion on the internals-core@ if need be. > > The only thing I currently do not have a clear solution for would be the > distribution of a single discussion between the two lists. I do see that > this might become problematic though. Obviously, people responding could > reference to a http://news.php.net/ link to show what they are responding > to, but this (c/w)ould become quite messy. > > My 2 cents, > > Stefan > > -- > > > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: guilhermeblanco@hotmail.com URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil --- ## #41615 — Lukas Kahwe Smith — 2008-11-01T17:20:26+00:00 URL: https://externals.io/message/41593#41615 · In reply to: #41612 > Behavioral change is exactly what is needed. The simplest way to > achieve > that is education and buy-in. A good start would be to document the > desired > behavior, in an isolated php-dev subscription page, in the form of a > _brief_ > terms of use, and have new subscribers acknowledge and agree to it. > There > could also be a cooling off period, where new subscribers are read- > only for > the first NN days - that'll let tempers and hair-triggers cool off. > The > core team is populated by some of the smartest people on the planet, > I'm > sure some other ideas can be bandied about and implemented to > achieve the > desired goal without resorting to moderation. We do have something along those lines: http://www.php.net/reST/php-src/README.MAILINGLIST_RULES Maybe it needs to be cut down (or just provide the key points at the top) and automatically appended to all emails (including the welcome email) .. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41616 — Mike Robinson — 2008-11-01T20:11:37+00:00 URL: https://externals.io/message/41593#41616 · In reply to: #41615 Lukas Kahwe Smith wrote: > > We do have something along those lines: > http://www.php.net/reST/php-src/README.MAILINGLIST_RULES > > Maybe it needs to be cut down (or just provide the key points at the > top) and automatically appended to all emails (including the welcome > email) .. There you have it. A dozen years on the list and I didn't even know that file existed. I'll bet there are many, many others. Brilliant idea adding a condensed version to the welcome emails and appending it onto all outgoing emails, maybe with a link back to the rules document above. It'll go a long way to decreasing noise. Best Regards, Mike Robinson --- ## #41617 — Ronald Chmara — 2008-11-01T23:01:50+00:00 URL: https://externals.io/message/41593#41617 · In reply to: #41615 > > http://www.php.net/reST/php-src/README.MAILINGLIST_RULES > > Maybe it needs to be cut down (or just provide the key points at > the top) and automatically appended to all emails (including the > welcome email) . Crontab a monthly mailing of the list rules to all list subscribers? +1 on appending a rules URL to all list traffic, -1 to appending rules to all email. ;) -Bop --- ## #41629 — Lukas Kahwe Smith — 2008-11-03T19:36:23+00:00 URL: https://externals.io/message/41593#41629 · In reply to: #41614 > The idea is awesome, but it'll definately not work. Sorry. > By creating an UG profile subscription will allow again everyone to > subscribe "a group" when it's really just one person that wants to > write something. So the UG idea will not work. this was the potential abuse situation i mentioned. i honestly think that most people will understand that people will not abuse this less bureaucracy approach if we feel that it will benefit PHP. if this fails, we can then decide on additional barriers, turing tests or whatever. also in response to Larry .. thats why I said we should also accept "virtual UGs", so that things do not need to be linked to a geographic location. for all we care, people can be members of how ever many UGs they want to be in. again it comes down to the question of "can we trust our community"? of course there will be abusers, but the question is if they are sooo large in numbers that they will prevent this from working? how many UGs are we expecting anyways? lets say we get 100 UGs to register. that would be quite an impressive number, but still manageable. if we get to 500 UGs, we would probably have to rethink the approach. like by seeing if we have mainly virtual or regional UGs etc. i think we can also weed out some fake UGs by just looking at their mailing list archives (no discussions means probably no UG). so if we do end up with 500 UGs that register and that want to actively take part in the discussion on internals, then i think this approach has validates itself: 1) it means we have helped quite a lot of UGs to form 2) it means we have grown the number of people that want to participate if this means we again have to review our discussion process, i am more than happy to do so. until then i feel this process could help get this list back to a more productive communication flow. it seems to me like a lot of the screaming and even personal attacks are caused by the fear that concerns might simply get lost in the noise. if we can do something to get rid of this fear (though probably never entirely), i think we have a chance of improving the general tone and productivity of this list. regards, Lukas Kahwe Smith mls@pooteeweet.org --- Next page: https://externals.io/message/41593.md?page=2