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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Then the subject start a no-human land discussion like the ns and it'll be moved to the closed [EMAIL PROTECTED] 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, On Sat, Nov 1, 2008 at 1:11 PM, Stefan Koopmanschap <[EMAIL PROTECTED]> wrote: > 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 [EMAIL PROTECTED] If the idea is > deemed good enough, a discussion on the closed list ([EMAIL PROTECTED]) 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9166-6902 MSN: [EMAIL PROTECTED] URL: http://blog.bisna.com Rio de Janeiro - RJ/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
