On Mon, Aug 1, 2011 at 7:25 PM, C <[email protected]> wrote: > On Tue, Aug 2, 2011 at 00:43, Rob Weir <[email protected]> wrote: >> If you have 20,000 zombie accounts then I think that is a serious >> argument for disabling all the existing accounts and starting fresh, >> with controlled access. > > There are just over 35k accounts on the Wiki now. About half are > "real" accounts... the rest were created and abandoned. This is > normal for any wiki. There was a large number accounts that were > created around 2006 by a spam bot (sequential numbered accounts etc). > This was before spam controls were put in place as it is now. > > Disabling all accounts is really counter productive for a Wiki. >
A wiki is a tool. Giving imperatives for how a tool should be used is not going to get you anywhere. A wiki can be used for many things.. We should be talking about the function of the tool. If the function of the tool is to create and edit documentation, including Admin Guides, user FAQ's, developer build guides, etc., then access should be controlled, and the PPMC should exercise oversight of the content. This is true for any tool that allows changes to documentation, whether it is SVN, the Apache CMS, or a wiki. The fact that it is used for documentation is what requires the access controls. That said, there may be other parts of the wiki that are not used for documentation. If so we should define which projects these are, so those can remain open for anyone to edit. > >> Don't delete content. Just disable accounts. If someone had one user >> id back in 1999 and get a different one today, is that the end of the >> world? If it is to many people, then we can either delete all >> accounts and let project members get the accounts of their choice, or >> we can reactive disabled accounts on request. > > It's not just about accounts. You've got a huge number of > contributors that have edited content on the Wiki... you > disable/delete all the accounts, and you have zero accreditation for > their contribution... just "user unknown" (for deleted accounts). How > is that fair to the thousands of past contributors? How does that > meet the requirements of any licenses attributed to the content? > Would you do something like this (remove all contributor history) in > the source code repos? I don't thinks so... so why would you consider > it for the Wiki? > You can't just disable the account and preserve the attribution? Not delete. Just disable. > Delete the dead accounts... OK, but you gain virtually zero from doing > this (unless you're migrating to Apache LDAP or some centralized user > account system)... but delete active accounts and tell people "just > get a new one"? I can't see that going over too well. > Well, what can you do to encourage direct participation in this Apache project? > >> We don't allow everyone to change the code in the repositories. We >> don't allow everyone to directly edit the project's website. The fact >> that there is a community does not mean that we allow 20,000 people, >> including spammers, to have accounts and give them the ability to edit >> all resources. > > A Wiki is not source code, and no one expects everyone to be able to > edit the website... Apples and radios (I can't say oranges because the > two things are so far removed it's apples and radios). Editing on the > OOoWiki is not editing all OOo resources. No one is saying the 35,000 > Wiki account holders should be source code committers as well. > A wiki is a tool. I don't care about the tool. The tool is not going to tell us how we run the project. The PPMC provides oversight for the project, not the tool. > >> Receiving contributions from contributors, reviewing them and merging >> them into the project, this is a key function of any healthy Apache >> project. Committers need to step up and help contributors get their >> contributions merged in. And if the number and frequency of >> contributions from a contributor is so high that it is annoying to be >> always processing their patches, then it is a good sign that that >> contributor should be voted in as a Committer ! > > Apples and radios again. Wikis are not source code repositories. > Again, focusing on the tool will not resolve this. Focus on the role of the tool. Should 35,000 people be able to edit documentation, even if they have not signed the iCLA? That is the real question here. > >> It is more accurate to say that OOo did not make a distinction here >> between a project wiki and a community wiki. > > It started as a public facing developer wiki, and the community jumped > in there and made use of the resource. There are many issues that > this history caused... like no Language Namespaces, everything is in > Main which forced the use of Subpages to introduce some sanity to the > myriad of languages... the mix of developer and user content and so > on. There is no doubt that there is a LOT of room for improvement, > but deleting all accounts? > > Anyway, I've said my bit. We're clearly on two different levels here :-P > I think some people may be projecting too much of the corporate-run OOo into Apache. Remember, with OOo relatively few people had direct access to the source code of the product, with the ability to directly commit source changes. It was under the centralized control of a corporation. The "community" was in other functions, such as documentation, marketing and especially translation. These groups formed as separate projects with the OOo umbrella project. That is not the way Apache works. There is no central corporate control. All commiters have access to the source code and can make changes. All commmitters can review and veto changes as well. At the same time, the committers are the ones who can change, review and veto website changes and documentation. The community that developers the bits and bytes of the project are the committers, under the oversight of the PPMC, under the oversight of the IPMC, under the oversight of the ASF Board. There are no other communities that are developing the bits and bytes of OpenOffice. The product development occurs here and now, on this list and no where else. If there are groups that think they can maintain an autonomous assistance, and directly change documentation on the wiki, but not join the project, not sign the iCLA, not participate on this list, then I think they will be risk a great disappointment in the near future. We should be thinking now of how we can reach out to them and explain to them that the community at Apache OpenOffice is comprised of users, developers and committers, that we work via a meritocracy, that we believe that the iCLA is important, and that the way to have increased access to project resources is to demonstrate commitment and merit and get voted in as a committer. -Rob > C. >
