Re: Forking is a Feature reactions?
- Original Message From: Eric Evans eev...@rackspace.com To: community@apache.org Sent: Wed, September 15, 2010 10:18:46 AM Subject: Re: Forking is a Feature reactions? On Wed, 2010-09-15 at 08:04 +0200, Dirk-Willem van Gulik wrote: Especially as the pattern seems to be conductive to personal gratification** more than community; and leads to patchcollections which are the work of love of a single person quite easily. And that seems to cause fragmentation on an end to end level. I.e. rather than scratching your own itch - and solving it at a product level - you create a small alternate reality in which you nullify the issue, in which you isolate - and then welcome people on your island - but you've not made the world a slightly easier place. Somehow it feels as if there is some driver lacking, some positive need to have communities collaborate. I believe you have this backward; distributed version control systems are more conducive to community than their centralized counterparts. With a centralized vcs, a select group of privileged individuals are given access, they are the gate keepers. Eh, no. That's exactly how Linux works, with people having protective attitudes towards their own trees: git only makes that mode of working easier. Here a committer's job is to *facilitate* inclusive work, not prevent it. Everyone else gets a working copy and is expected to create a patch (or patches) and then work to convince a committer to apply them. That's not the Apache model, fwiw. Collaboration means you work as equals, committer status or not. A distributed version control system is a measure toward eliminating that have/have not distinction; it reduces the barrier to contribution. No it doesn't. The learning curve alone is a barrier to its adoption. It just means you have the same access to the history as anyone else, and can develop on branches with far greater ease. Github is the great new thing here, not git itself. If github were open source we'd probably be using it at Apache already in some form. Instead of a working copy you get a full working repository. Contributors can have long running branches where they work on large features while easily keeping in sync with upstream changes. And when the contributor repos are public, others can follow their progress and provide feedback and collaborate. If useful changesets that are languishing in random repositories and are not making it upstream, that is a social problem, not a technical one. Yes, but that just begs the point: this thread is about the social implications of the choice of vc tool, and the aforementioned author of the blog post seems to think forking in all its forms is a good idea for societies. Somehow I doubt that's the case. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Torsten Curdt tcu...@vafer.org To: community@apache.org Sent: Wed, September 15, 2010 11:10:21 AM Subject: Re: Forking is a Feature reactions? Everyone else gets a working copy and is expected to create a patch (or patches) and then work to convince a committer to apply them. That's not the Apache model, fwiw. Collaboration means you work as equals, committer status or not. Hm? Reality check? Usually patches only get applied if committers think they are good enough and worthy to apply. Not every patch gets applied no matter what. And how is that dependent on the version control tool? See, it isn't. It's a function of the community's value system. A distributed version control system is a measure toward eliminating that have/have not distinction; it reduces the barrier to contribution. No it doesn't. I could create the longest thread on this list by saying Yes, it does! ...but maybe let's say - that's what people call a difference in opinion ;) That shouldn't prevent more knowledgable people from correcting you tho. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Eric Evans eev...@rackspace.com To: community@apache.org Sent: Wed, September 15, 2010 11:13:15 AM Subject: Re: Forking is a Feature reactions? On Wed, 2010-09-15 at 07:32 -0700, Joe Schaefer wrote: With a centralized vcs, a select group of privileged individuals are given access, they are the gate keepers. Eh, no. That's exactly how Linux works, with people having protective attitudes towards their own trees: git only makes that mode of working easier. Here a committer's job is to *facilitate* inclusive work, not prevent it. I don't think the Linux work-flow is a particularly good example for anything other than Linux. The problem set certainly doesn't map well to any of the projects I work on. Everyone else gets a working copy and is expected to create a patch (or patches) and then work to convince a committer to apply them. That's not the Apache model, fwiw. Collaboration means you work as equals, committer status or not. I agree with the sentiment, but the choice of distributed vs. centralized vcs is a technical one. You can be as open and inclusive with contributors as you want, without commit access they're relegated to a second-class work-flow. I can appreciate that, but the stock answer to that is just give them commit. High barriers to committership is not what Apache is about. A distributed version control system is a measure toward eliminating that have/have not distinction; it reduces the barrier to contribution. No it doesn't. The learning curve alone is a barrier to its adoption. It just means you have the same access to the history as anyone else, and can develop on branches with far greater ease. Github is the great new thing here, not git itself. If github were open source we'd probably be using it at Apache already in some form. I disagree, Github adds a lot of value, but I'm thinking in terms of the differences between distributed vs. centralized systems. The argument is the same with or without Github, and could likewise include Mercurial, Bazaar, etc. Instead of a working copy you get a full working repository. Contributors can have long running branches where they work on large features while easily keeping in sync with upstream changes. And when the contributor repos are public, others can follow their progress and provide feedback and collaborate. If useful changesets that are languishing in random repositories and are not making it upstream, that is a social problem, not a technical one. Yes, but that just begs the point: this thread is about the social implications of the choice of vc tool, and the aforementioned author of the blog post seems to think forking in all its forms is a good idea for societies. Somehow I doubt that's the case. It doesn't frighten me. It does give me pause because I believe there's an important role for a set of central services for projects (and for societies in general). As far as Apache goes, it's a virtual organization whose roots lie in the stuff we have stored in various datacenters. Nevertheless there is a palpable sense of what it means to do work at Apache, and part of that illusion is provided by our centralization. I do wonder how we'd manage to maintain that illusion if we completely decentralized our core workflows. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Santiago Gala santiago.g...@gmail.com To: community@apache.org Sent: Wed, September 15, 2010 11:50:34 AM Subject: Re: Forking is a Feature reactions? On Wed, Sep 15, 2010 at 5:23 PM, Joe Schaefer joe_schae...@yahoo.com wrote: (...) It does give me pause because I believe there's an important role for a set of central services for projects (and for societies in general). As far as Apache goes, it's a virtual organization whose roots lie in the stuff we have stored in various datacenters. Nevertheless there is a palpable sense of what it means to do work at Apache, and part of that illusion is provided by our centralization. I do wonder how we'd manage to maintain that illusion if we completely decentralized our core workflows. It is amazing how you (and I mean a big y'all of people negating distributed SCM along those last 5 years or so) can keep the illusion that a technical solution (called centralization here) can keep an organization together more than a set of core values can. It comes from experience with dealing with younger projects in the Incubator that are not so enthralled with svn's workflows, and the social problems that seem to result from those attitudes. Eric is a relatively new committer at Apache and he still talks about his role as being like a gatekeeper. That's not something he picked up from us. While I agree that changing tools, like changing stylesheets or electing a new board, changes an organization, I don't believe at all in subversion or even in centralized SCM as a shared ASF value. Good because although some people may think that, I'm not one of them. The tool we use is serving the org well and that is my overriding concern. The jury's still out on whether migrating wholesale to git instead of just providing git mirrors is actually in the org's best interests. The license, the belief in collective decision making, our history, etc. are central. Not the technology we use for SCM. We already changed from cvs to svn and our world stayed reasonably similar. Well svn was billed as a better version of cvs. It's not like the workflow changed much between them. I see the dscm is an unsuitable workflow for collaborative development meme as this: a meme. You can think of git as just a local backup for your changes and a tool for patch handing like quilt blended together. This is often how I think about it when I'm using git svn for legacy subversion sites like the ASF. If you add github for a public remote backup this would be similar to having a quilt setup exported as a public share in one of those cloud backups... only with standardized and very efficient transfers AIUI github already carries our mirrors, so we're already *doing* that. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Eric Evans eev...@rackspace.com To: community@apache.org Sent: Wed, September 15, 2010 1:02:17 PM Subject: Re: Forking is a Feature reactions? On Wed, 2010-09-15 at 09:05 -0700, Joe Schaefer wrote: It is amazing how you (and I mean a big y'all of people negating distributed SCM along those last 5 years or so) can keep the illusion that a technical solution (called centralization here) can keep an organization together more than a set of core values can. It comes from experience with dealing with younger projects in the Incubator that are not so enthralled with svn's workflows, and the social problems that seem to result from those attitudes. Eric is a relatively new committer at Apache and he still talks about his role as being like a gatekeeper. That's not something he picked up from us. I'm going to work really hard at not being offended by this. I do not view myself as a gatekeeper, and more importantly, that is not a role I desire (for myself or anyone else). However, I'm not self-deluded enough to believe that because I aspire to lofty ideals, that I somehow do not possess access to a controlled resource _that others do not_. Then perhaps your portrayal of the typical role for an Apache committer was exaggerated for effect. When the day comes that most of our patch submissions to jira are git-formatted (and hence incompatible with svn) I will be far more receptive to the idea that svn is a greater barrier to community participation than svn is. If anything, my interest in a decentralized version control system is to even the playing field, remove obstacles, and empower contributors. Sure, but you have to ask yourself why it is that Apache committers tend to make a *lot* more noise about this than our contributors do. I suspect the motivation is more because git is so powerful than the more idealistic notion that git levels the playing field. But I commend your idealism nonetheless. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Eric Evans eev...@rackspace.com To: community@apache.org Sent: Wed, September 15, 2010 2:30:25 PM Subject: Re: Forking is a Feature reactions? On Wed, 2010-09-15 at 10:19 -0700, Joe Schaefer wrote: I do not view myself as a gatekeeper, and more importantly, that is not a role I desire (for myself or anyone else). However, I'm not self-deluded enough to believe that because I aspire to lofty ideals, that I somehow do not possess access to a controlled resource _that others do not_. Then perhaps your portrayal of the typical role for an Apache committer was exaggerated for effect. I had thought I was precise in my wording, and I've reread my messages to this thread, can you point me at the alleged exaggeration? Or is it that you in general object to the term gatekeeper in reference to the relationship between someone who possess access rights to a controlled resource, and someone who does not. You could just as easily describe committers here as stewards or facilitators which would be far more apropo of what we try to teach people about committership. Gatekeeper is about as loaded as calling them traffic cops, so yeah it's objectionable when applied to Apache people. When the day comes that most of our patch submissions to jira are git-formatted (and hence incompatible with svn) I will be far more receptive to the idea that svn is a greater barrier to community participation than svn is. ^^^ Sorry I meant to write git there. See http://stackoverflow.com/questions/708202/git-format-patch-to-be-svn-compatable AIUI compatibility is a feature that will be included in svn 1.7. Contrary to the opinions of some the git folks and the svn folks do collaborate on feature sets. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Torsten Curdt tcu...@vafer.org To: community@apache.org Sent: Wed, September 15, 2010 2:16:42 PM Subject: Re: Forking is a Feature reactions? To try to put my finger on the key distinction I've seen, a centralized workflow puts demands on people to make promises up front. Not necessarily. Enough people start playing with something. Just to see if it works. All that happens on their local system though. I have never seen a project where everyone is having his/her own svn branch just committing away all experiments. I didn't mean to imply that using svn guarantees success. Far from it, success at Apache is pretty challenging for Incubating projects. IOW before you start that work on a snazzy new feature, you have to explain to people what you're doing and why, and to set expectations for the final outcome. That's because they will be exposed to your work whether they like it or not, because it all gets thrown onto the commit list. Only if you actually have the right to commit. Which is exactly one of the points mentioned before. Well if someone shows up on a dev list and says all those things, and has a little bit of an early implementation to review, seems to me they should be allowed to work directly in the svn repo. Yes, it involves someone promising to do something, and the community actually making a minor bet on their success. Gradually people learn from the experience, and if it's a positive one they continue to make collective bets on that person's work product. If it doesn't work out the committer disappears and nothing much is lost. I don't see what the big deal is about right to commit as if it's inherently something difficult to obtain. It shouldn't be that way (PMC membership can be another story however, but that's not tied to any vc tool). It's just the right to do some work on the project where full access to the vc tool is appropriate. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
- Original Message From: Ross Gardler rgard...@apache.org To: community@apache.org Sent: Wed, September 15, 2010 7:18:17 PM Subject: Re: Forking is a Feature reactions? On 15/09/2010 19:32, Tony Finch wrote: On Wed, 15 Sep 2010, Santiago Gala wrote: On Wed, Sep 15, 2010 at 8:04 AM, Dirk-Willem van Gulik di...@webweaving.org wrote: Especially as the pattern seems to be conductive to personal gratification** more than community; and leads to patchcollections which are the work of love of a single person quite easily. And that seems to cause fragmentation on an end to end level. I.e. rather than scratching your own itch - and solving it at a product level - you create a small alternate reality in which you nullify the issue, in which you isolate - and then welcome people on your island - but you've not made the world a slightly easier place. Somehow it feels as if there is some driver lacking, some positive need to have communities collaborate. What makes you think that without github people effectively tries to get patches upstream? IMO, most of may patches have remained forever in my HD until I deleted or a crash destroyed them. Right. In my experience a lot of places that deploy open source software will fix little niggles (gaps in functionality / integration impedance mismatches / whatever) in an expedient manner. They are often reluctant to expose their changes because they are too specific or scruffy. I don't work with a single team of developers, I work with hundreds of teams spread across the UK. I mention this because I suspect this gives me a broader personal experience of the realities of open source ***use*** than the majority of folk here. In my opinion the above statements are absolutely correct. That is, the vast majority of local modifications never make it anywhere near project maintainers. GIT does not, and will not, change this on its own - it's a cultural issue not a tools issue. Sorta begs the question of whether such changes *should* be published. Github puts a *public* **indexable** fork one click away. It gives you a backup, so that there is incentive to have all your microchanges up asap. Right, and it seems to be encouraging people to make their previously private patches public. I agree with you that dirkx is observing a problem that was always there but previously less visible. Whilst I agree, I do not believe GIT will help change this. As a project maintainer I am unlikely to monitor X branches of my code, I'm going to expect people to tell me the patches I should consider. However, in this situation GIT does help due to its (allegedly) superior merge handling. Merging aside, you raise a very good point. Just about every project I've ever seen at Apache could use more *attention* - that is the scarce resource that individuals try hard to protect. Fortunately it's not a conservative resource, in that if a project is successful in bringing in new people, the amount of attention they can bring to the project as a group increases. It doesn't always work out that way, some committers demand more attention than others do, but the gist of it is that overall it's better to have too many committers than to not have enough. That is why the Incubator likes to see growth and diversity in its podling's committer base. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
[NOTICE] compromised jira passwords
Hello Apache community@ [1], As you are probably aware we have been working to restore services that have been compromised by a very targetted attack against Apache's jira installation. The good news is that jira is back online, with bugzilla and confluence soon to follow [2]. The bad news is that the hacker was able to rejigger jira's code to sniff any cookies and passwords sent to the server between April 6 and April 9. If you used jira at all this week, including via IDE's that interface via SOAP, it is IMPERATIVE that you take time to immediately reset your jira password, and possibly your ldap password if those match up. If you have admin privs in jira your password was reset by us, so you'll need to use the password reset form in jira to regain access. To have a reset password mailed to your contact information in jira, visit https://issues.apache.org/jira/secure/ForgotPassword!default.jspa When you do login to jira be sure to double-check your contact info. To change your ldap password login to people.apache.org and run /usr/sbin/passwd, or else visit https://svn.apache.org/change-password . Thanks for your patience and diligence in this matter. A blog post will be forthcoming which will provide details of the attack and what we have done to mitigate future hack attempts. [1] feel free to forward this note to any other apache mailing list, public or private. [2] at this time we do not believe the hacker compromised the confluence and bugzilla installs, but we are awaiting confirmation from our admins before bringing those back online. - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: You can at.....
Dirk-Willem van Gulik [EMAIL PROTECTED] writes: So I'll do the deed - any objections to inviting Tim in here ? Feel free to drop Tim of the Cc to preserve dignity/privacy. I wouldn't mind if you also forget to unsubscribe him after this discussion ends. -- Joe Schaefer
Re: You can at.....
Dirk-Willem van Gulik [EMAIL PROTECTED] writes: On 28 Jan 2003, Joe Schaefer wrote: Dirk-Willem van Gulik [EMAIL PROTECTED] writes: So I'll do the deed - any objections to inviting Tim in here ? Feel free to drop Tim of the Cc to preserve dignity/privacy. I wouldn't mind if you also forget to unsubscribe him after this discussion ends. Nope; I do not think that that was the pattern agreed to for this list (though this list can change the rules any time they can get consensus over it) - once invited in, is invited in as part of the [EMAIL PROTECTED] Even better! -- Joe Schaefer
Re: You can at.....
Steven Noels [EMAIL PROTECTED] writes: Dirk-Willem van Gulik wrote: So I'll do the deed - any objections to inviting Tim in here ? As the factual proposer: sure! Noone objects to Tim's invitation. I personally would like to ensure that since he's here now, he can also expect to stay here as long as he likes. I'm glad to relearn that our prior vote already established that. -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Open community (was ... secret discussions ...)
Joshua Slive [EMAIL PROTECTED] writes: On Tue, 28 Jan 2003, Sander Striker wrote: community@ is the only ASF wide list that is opt-in and not bound to a certain topic (like infrastructure@ for example). committers@ always reaches _all_ committers if they want to participate or not. So that list is not an option. The fact that it is the only ASF-wide list for discussion seems to be an argument for opening it, not closing it. We did NOT vote to close the list. We voted to limit access to committers AND INVITED participants. If Andrew does not wish to INVITE Tim's participation, it is _Andrew_ who is blocking Tim's access here. -- Joe Schaefer
Re: email notification done...sorta
Noel J. Bergman [EMAIL PROTECTED] writes: [...] I was going to reply that perhaps the choice of usemodwiki was a good one as a turnkey thing, but perhaps not the best choice for the long term due to the lack of competent Perl programmers willing to contribute. At the moment, Danny Angus and Rick Bowen are the two who've stepped forward, and both of them have other primary involvements, not to mention this being the first week that many people are back from spending time with family. I was/am also planning to help, and I did look over the usemodwiki source to get acquainted with it. However, I don't have any experience with wikis, nor with RSS, so I also need to bring myself up to speed on the technology- according to *my own* (free) timetable. Part of that learning process is simply watching how experienced people operate, and then trying to mimic their behavior. Or not, as the case may be. On the other hand, we've a lot more competent server-side Java contributors. Right. To my knowledge, there are only a dozen or so active committers that work on perl-related ASF projects. -- Joe Schaefer
Re: as well as the critical notion of imagined community... :-)
Ben Hyde [EMAIL PROTECTED] writes: [...] That paper references a lot of obviously hard won models of what community is, so now I'm going to have to go read a mess of stuff. Definitely interesting reading. I find it's amazingly rare to find anything about community that isn't moronic, simplistic, or romantic. Or worse argues that community is just another victim of modern life. I think quite the contrary that the net is a typhoon of community building. There was a great PBS special on Benjamin Franklin a few weeks ago. While quoting Franklin may be hitting below the belt to an American, his brilliant speech to rescue the signing of the US Constitution is certainly worth a read. Here's a url describing the particulars (the actual speech is linked within the main text): http://www.pbs.org/benfranklin/l3_citizen_founding.html -- Joe Schaefer
Re: [proposal] creation of communitity.apache.org
Justin Erenkrantz [EMAIL PROTECTED] writes: --On Monday, December 2, 2002 8:39 AM +0100 Nicola Ken Barozzi [EMAIL PROTECTED] wrote: I don't think we are talking about complete personal websites with blogs and such, with rants and honeymoon pictures, but about some pages that explain what the person does, who he is, and not much more. Of course we are. We're saying that anyone can post whatever they want on their apache.org site. That's what I'm against. I don't want people posting their honeymoon pictures or their Beanie Babies collection. But, as soon as we say, 'you can post whatever you want,' that's what is going to happen. Saying otherwise is foolish. Color me foolish then. I just can't wait to have my very own dot on Stephano's cool SVG image. Unfortunately, Roy's site is sort of an example of what I don't want to see. However, what I believe Sam hasn't realized is that Roy *just* moved his site there from the UCI servers while he looks for a new home for his web site. (Roy will correct me if I'm wrong.) I trust Roy not to post anything inappropriate, so I'm not going to complain because I believe it's temporary. Yet, not every committer has earned my trust in the way Roy has. If your description is accurate, I see Roy's behavior here as completely consistent with Jon's placement of an idiot.html url within the Jakarta community documents. Is this the Apache Way? -- Joe Schaefer
Re: Rules for Revolutionaries
Stefano Mazzocchi [EMAIL PROTECTED] writes: [...] I believe it was a mistake to allow two different codebases to share the same name. I'm not convinced that having two codebases is necessarily a mistake. So far the discussion here seems to have centered around the concerns of the existing tomcat developers. I'd like to know what the tomcat users (ie. the future tomcat developers) think of the 3.x/4.x division. -- Joe Schaefer
Re: [important proposal] Cocoon as official Apache project
[Not Cc'd to Apache Cocoon cocoon-dev@xml.apache.org] Stefano Mazzocchi [EMAIL PROTECTED] writes: [...] Also, note that community@ is *NOT* asked to vote but only Cocoon committes. I copied community@ to let people know the process is underway and I wanted to do it in a very open way. Whew- That's a relief! I didn't catch the CC: to cocoon-dev in your original post. [...] How many cocoon committers are there right now? As you can see from http://xml.apache.org/cocoon/who.html there are: 19 active committers 5 inactive committers 14 emeritus committers see the page for a definition of their status and their names. Thanks for the link. Prior to posting, I did try looking for this info myself on the xml.apache.org site. There seems to be a link loop though: http://xml.apache.org/whoweare.html - /roles.html - /whoweare.html ... I got frustrated after a few cycles, so I figured it's just easier to ask :-) [...] Hope this helps. It did. Thanks again. -- Joe Schaefer
Re: [important proposal] Cocoon as official Apache project
Stefano Mazzocchi [EMAIL PROTECTED] writes: [ I want to preface my comments by first thanking you for [EMAIL PROTECTED] Secondly, at the moment I'm inclined to affirm your proposal, but I need to develop some guiding criterion on which to base a vote. I don't want to be in a position where I feel obligated vote +1 on every similar request, especially when I have no feeling for how many of them are coming :-) ] [...] Unfortunately, the ASF members thought that the same model could well apply to projects which did not release software directly (unlike HTTPD did) and decided to use the same model for jakarta and xml (which don't release software directly, but add another level of indirection with subprojects). Can you describe the current release process for cocoon, emphasizing the problems with the current system? Is there a public document that chronicles the issues? [...] In order to avoid stupid PMC elections, I'll be in favor of having the PMC composed by *all* committers that ask to be part of it. This to imply that committers and legal protector share the same duties and priviledges. How many cocoon committers are there right now? [...] 3) what does it mean for Cocoon? Being a project allows us to host several different incubation-stage efforts underneath. Cocoblog, wyona, forrest, cocoon-related IDE plugins could be possible additions. Of course, with the idea of promoting them as top-level projects when they are successful from a community perspective. How will the cocoon PMC be better positioned to address the needs of such subprojects than the current jakarta/xml PMC? How do you foresee cocoon's PMC addressing the current troubles with subproject releases? [...] 5) isn't this unfair against the other sub-projects that remain contained, therefore with less visibility? I don't know. Here I'm just stating the intention to move Cocoon to top-level and I know the ASF board is very open to projects willing to move out of their containers. But the ASF will *NOT* force projects to take this action. If other communities feel they should deserve top-level projects, they should make a proposal like this and ask the board instead of complaining with us that we do it. Among jakarta/xml projects, how widespread is the desire to abandon the container PMC? Have there been other reorganization attempts in the past? -- Joe Schaefer
Re: idiot.html
robert burrell donkin [EMAIL PROTECTED] writes: one of the continual battles we've had at jakarta is policing the mailing list and general in particular. people wanting to join a mailing list from the jakarta list have to go through two pages to get the actual lists in order to try to reduce the need for people to police the list guidelines. but this doesn't seem to be enough. we still get people posting who haven't taken the time or effort to read what's been created to help them. jon started taking a lot of the responsibility for policing very soon after the change from [EMAIL PROTECTED] to [EMAIL PROTECTED] he started off with elan and humour but over the years his responses got shorter and more curt as it became a chore. hence the jon.html which had to be used when people took it too personally. one problem which has become apparent over the last year or so is that jakarta lists are very widely mirrored - including onto news. this means that people post to our lists never having read the list guidelines or (as has happened in a couple of cases) not even realizing that they are on a mailing list. Thanks alot for taking the time to dispassionately explain the situation *such as it is*. It's exactly the kind of answer I was hoping for. Unfortunately I don't know what sort of magic is required to make everybody happy, but I do know there are other online developer communities that have experienced similar growing pains. It might not hurt to survey some prior art; IME perl's p5p developer list is exceptionally well-managed. I don't have first-hand experience with the php developer community, but from my distant vantage point, they seem to be managing their growth pretty well (at least angst-free). -- Joe Schaefer
