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
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
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.orgPS: I have published the above text as an RFC on the wiki .. http://wiki.php.net/rfc/managinglisttraffic
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
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
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).
-
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. -
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. -
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. -
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
-<redacted>, PHP sub-project "hidden/CC lists and chats"
-<redacted>, PHP core current C contributors and debuggers
-<NA> 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
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
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
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.
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
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 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
I have more faith in our devs then that.
[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
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@?
--
</Daniel P. Brown>
http://www.parasane.net/
daniel.brown@parasane.net || danbrown@php.net
Ask me about our current hosting/dedicated server deals!
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@?
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
On Fri, Oct 31, 2008 at 3:15 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
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.
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.
--
</Daniel P. Brown>
http://www.parasane.net/
daniel.brown@parasane.net || danbrown@php.net
Ask me about our current hosting/dedicated server deals!
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.
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
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
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
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
Lukas Kahwe Smith wrote:
We do have something along those lines:
http://www.php.net/reST/php-src/README.MAILINGLIST_RULESMaybe 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
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
Lukas Kahwe Smith wrote:
Hi,
So some core developers as well as lurking end users have noted that the
<snip>
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
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
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
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:
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
--
--
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
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:
- it means we have helped quite a lot of UGs to form
- 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
how many UGs are we expecting anyways?
there are already 206 active local UGs registered in
phpclasses.org[1], so I guess its the very least we should expect.
regards,
Igor.