2009/9/3 Peter Miller <peter.mil...@itoworld.com>: > 2) We need to ensure that every contributor is on-balance making the > dataset better, not worse. If the contribution is in doubt we owe it > to other contributors to investigate and respond.
This is a situation where the contributions are in doubt, at least in some areas. I think we could borrow some of the conventions from software projects, where the "current" state is considered to be correct until proven incorrect. We already have commit messages like in software repositories so maybe it's a good idea to make the commit messages obligatory too -- obligatory in the sense that any changeset without a good description can be reverted for just that reason by other people. In a software project a commit message needs to: * describe what the change does, * why it's needed (rather than "This changes the way we start up"), * how it does it and why this is the right way to do it (rather than "This fixes a segfault"). Any commit that doesn't have a message containing these three elements is liable to revert and in most cases is reverted until the submitter comes up with a better description. The revert message obviously needs to state what is wrong with the change or the message, sometime by just referencing some rule number (even in wikipedia you have revert messages like "Violates F.O.O.B.A.R.X.Y.Z. section #4"). For OSM the rules would be much more relaxed than in software projects. Since I'm used to writing commit messages I wouldn't mind such a change but maybe I'm crazy and it's way to much bother for normal mappers. Is it? > ... > 8) Once someone has been identified as a problematic contributor then > one only needs to perform a brief of inspection of subsequent edits > before reversion future changesets. Liam123 is in this category now. > 9) If the problem continues (Liam123 is actually probably in this > category) then one puts then on 'virtual ban' where their edits get > reverted with no inspection of the merit of the changes unless the > person contacts a sys-admin and says they have grown-up and want > another chance. Couldn't we just lock such accounts until the person contacts the admin / privileged person, and not have the objects in the database spammed with bogus history? Cheers _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk