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

Reply via email to