Re: Common documents across the ASF
On Thursday, June 19, 2003, at 05:31 AM, Glen Stampoultzis wrote: At 01:09 PM 19/06/2003, you wrote: Why NOT have shared documents? I've heard it said that the CVS organization is the barrier. OK, so why not look at what reasonable steps could relieve that barrier? What would happen if we had an Incubator module open to all ASF Committers? Would that lower the barrier and increase reuse? The reason why it hasn't been done is simple... because no one has actually stepped up to find all the redundant information and send patches to the various projects to fix it up. CVS access isn't the problem. Finding someone with the itch, time and motivation is. it's not as simple as that. the proposal is not only to create common documentation (which would be cool) but also to remove all existing documentation on subjects which should be common. this means removing most of the pages on the jakarta website. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common documents across the ASF
There's the committers module. Every committer has access to this one. On 19.06.2003 05:09:39 Noel J. Bergman wrote: Why NOT have shared documents? I've heard it said that the CVS organization is the barrier. OK, so why not look at what reasonable steps could relieve that barrier? What would happen if we had an Incubator module open to all ASF Committers? Would that lower the barrier and increase reuse? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
There's the committers module. Every committer has access to this one. I know. It isn't part of the site deployment, but I suppose that it could be used that way, perhaps under the docs/ directory (for example), with a small change to the update commands. Also, the Committers module is, AIUI, considered to have private content. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 8:52 AM There's the committers module. Every committer has access to this one. On 19.06.2003 05:09:39 Noel J. Bergman wrote: Why NOT have shared documents? I've heard it said that the CVS organization is the barrier. OK, so why not look at what reasonable steps could relieve that barrier? What would happen if we had an Incubator module open to all ASF Committers? Would that lower the barrier and increase reuse? Hang on a minute. Why does everyone need commit access to this one? All ASF members have commit access to it. And more than a few others. I'm sure it isn't that hard to find someone to commit sent in patches. Is generating and sending in a patch considered too high a barrier? Sander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
Sander, You said, Hang on a minute. Why does everyone need commit access to this one? All ASF members have commit access to it. I had asked, What would happen if we had an Incubator module open to all ASF Committers? Would that lower the barrier and increase reuse? Are you referring to ASF Members, as opposed to Committers, having commit access to the site module? If so, I don't disagree that perhaps the ASF site module need not be opened, but is there a reason not to allow all Committers to update common documents related to procedures and other project matters? Perhaps not in the site module, but in another suitable module? I'm sure it isn't that hard to find someone to commit sent in patches. Is generating and sending in a patch considered too high a barrier? According to the posts in infrastructure@, at least some people would sooner copy text from a page into their own CVS than submit patches. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common documents across the ASF
At 01:09 PM 19/06/2003, you wrote: Why NOT have shared documents? I've heard it said that the CVS organization is the barrier. OK, so why not look at what reasonable steps could relieve that barrier? What would happen if we had an Incubator module open to all ASF Committers? Would that lower the barrier and increase reuse? The reason why it hasn't been done is simple... because no one has actually stepped up to find all the redundant information and send patches to the various projects to fix it up. CVS access isn't the problem. Finding someone with the itch, time and motivation is. Glen Stampoultzis [EMAIL PROTECTED] http://members.iinet.net.au/~gstamp/glen/
Re: Common documents across the ASF
Tim O'Brien wrote: no, the barrier is not high. Yes, it is too high for many, many potential contributors. No it isn't, I think you are confusing the fact that people don't generally like to contribute documentation. Instead of lowering the barriers for potential contributors, we need to do a better job of creating an atmosphere where a non-committer knows that a patch submission will not sit in Bugzilla for months before being discovered. I would tend to agree with your rant and your suggestion on how to earn karma. However, committers on individual projects are using their own CVS modules to create copies of these documents. We on the James project have done this with a few pages and link to some Jakarta or Apache website pages depending on which we think is best written/most updated. So, I don't see the issue as people not wanting to write documentation, just individuals taking the path of least resistance. Honestly, I'm curious as to how much authority the individual PMCs should be exercising to define these processes. Even a process as simple as creating an account for a first time creator can have variations. This is a silly example, but the Jakarta page says to cc this request to pmc@, while we at James are cc'ing [EMAIL PROTECTED] Also the James project might want to specify that lazy consensus for a new committer vote is waiting 72 hours from the time the vote is called. Other projects may have this a different time, or even just think the James project is making a mountain out of a mole hill and should get over themselves. Isn't to some extent these processes decisions up to the PMC? Do we really have so many variations that the board (or members or whoever) need to decide what to centralize and unify? -- Serge Knystautas President Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
Glen, The reason why it hasn't been done is simple... because no one has actually stepped up to find all the redundant information and send patches to the various projects to fix it up. CVS access isn't the problem. Finding someone with the itch, time and motivation is. That is the answer I would have hoped (and expected) to hear. It wasn't what I heard. A bit of background. I had made a comment about shared documents on infrastructure@ in response to someone saying that for most Java programmers, Apache is Jakarta, and they never ever look at www.apache.org/dev. In response to my comment about the desirability of centralizing sharing policy and procedure documents to make them easier to reference and maintain, I heard: - you could move the dead content to the ASF but you would not be moving the community that created and maintains it. - if these pages were removed into the central site then this would be a much bigger barrier and take a lot more energy. unless i felt very strongly, i'd probably not bother. i'd probably add the information to a jakarta subproject website. - it's not reasonable to expect the jakarta pmc to enforce what you describe. i would not support any veto of a change to the website on the basis that the material should have been submitted to the ASF site. Emotional, real or otherwise, there is at least a non-unique perception that having to submit a patch is far more work that vs committing directly. That was one of the reasons given for why people copy documents into their own CVS space, rather than build shared content for the ASF community. Right now the sample size is tiny, so I would not make any claims as to the overall attitude towards shared content. I hope that your view is the more common one. Meanwhile, I have created http://nagoya.apache.org/wiki/apachewiki.cgi?PoliciesAndProcedures, which just attempts to collect and collate policies and procedures pages that people (in the initial dump, me) think have shareable content. It is a first step to let us all [step] up to find all the redundant information. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
I don't see the issue as people not wanting to write documentation, just individuals taking the path of least resistance. I agree. Honestly, I'm curious as to how much authority the individual PMCs should be exercising to define these processes. Even a process as simple as creating an account for a first time creator can have variations. I think that the answer depends upon within whose domain the item resides. In the case of account creation, that action item resides in the infrastructure group. They, and no one else, should have control over the procedure(s) involved with respect to the action item. With respect to internal project management, that's the PMC's call. In the case of project management, each PMC ought to be able to define its own policies and procedures within the broad guidelines provided by the ASF (perhaps via Incubator and/or Jakarta as the holder of best practices.). If a PMC wants to do things differently, or subclass a procedure, that's up to the PMC, IMO. I don't see shared documents as being about control. I see it as being about reuse and ease of access. On the latter issue, I've started a page at Greg's suggestion (and looked on the Wiki first to see if there was one), whose sole purpose is to act as a TOC. If an existing Wiki page had already collated information on a particular topic, I just linked to that Wiki page (re-use) rather than re-implement that effort. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
I'm tired of having someone propose a new committer because he or she thinks that the patch submission process is too difficult. In my case, I'm talking about existing Committers. *If* CVS commit rights for Committers are widely perceived to be a barrier, then perhaps there ought to be a place where Committers can equally contribute to a shared document set. But the whole world? Use the Wiki. I think you are confusing the fact that people don't generally like to contribute documentation. Although I consider this orthogonal to shared pages (people can cut and paste vs. link on the Wiki as easily as the static sites), I do believe that lowering the barrier (CVS or XML) has demonstrably increased documentation contribution. A lot of documentation has been building on the Wiki. Perhaps more than on the official sites over the period. Some projects are moving their FAQ pages to the Wiki. I am not promoting or discouraging that approach, but am curious to see how it evolves. In the case of James, we have had far more contribution to our pages via the Wiki from normal users, than their taking time to learn the XML documentation scheme. Users feel directly empowered. But I consider shared content and Wiki use to be unrelated. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Common documents across the ASF
On Thu, 19 Jun 2003, Noel J. Bergman wrote: I think you are confusing the fact that people don't generally like to contribute documentation. Although I consider this orthogonal to shared pages (people can cut and paste vs. link on the Wiki as easily as the static sites), I do believe that lowering the barrier (CVS or XML) has demonstrably increased documentation contribution. Agreed, there is a problem in that guidelines and policies are duplicated across the apache.org domain and sometimes presented in draft form on the site. This leads to confusing situations where two people disagree on process, who can propose a release, what is a PMC, etc. In the case of James, we have had far more contribution to our pages via the Wiki from normal users, than their taking time to learn the XML documentation scheme. Users feel directly empowered. But I consider shared content and Wiki use to be unrelated. I consider these issues to be unrelated as well. I'm not questioning the value of the Wiki, I think it has worked for the projects that have decided to use it, but from what I see it is no substitute for documents that need to be viewed as policy. The docs I think people are talking about are more analogous to the Magna Carta, or a legal document. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common documents across the ASF
Tim, you missed my point. Sander asked whether commit access is, or is seen as, a barrier. The answer is: yes. It is one of many barriers that we have. You're pointing out that those are in place for a reason. Well, yeah. For example, commit priviledge is something which is earned by individuals and given out by a community, hence facilitating a community feel. Someone who is granted committer status usually feels honoured to be asked to be part of the team. Works nicely. Now the catch: for some stuff, I happen to think some current barriers don't make sense. They result in lots of unneccessary duplication (of effort and material). general documentation is one of those areas. A low barrier to cross-project co-operation on stuff like that will help avoid pages like http://httpd.apache.org/dev/nt-cvs-ssh.txt IOW, this is not about technical difficulty or community dynamics, it is about managing the path of least resistance for a common cross-project concern which is completely orthogonal to the reason(s) for the existence of our barriers. cheers! - Leo Tim O'Brien wrote: rant-disclaimer/snip/stuff/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
