User talk:Sletuffe/2008 talk

From OpenStreetMap Wiki
Jump to navigation Jump to search

Edit war about smoothness

Please try to find an agreement on how to find a solution on this edit war. Use the mailing list talk@openstreetmap.org where I raised a thread about your conflict which happens since 7 days now (title is "Edit war on the wiki "map features"". -- Pieren 16:28, 25 November 2008 (UTC)

RFC and Vote times

I just read your comment "I know many people will be frustrated that the voting period is too long, but there have been much concerns on the talk list, that going too fast only leads to frustration, frustration lead to wrath, wrath lead to anger, and anger, as any one knows, leads to the dark side of the force." on Proposed_features/mtb:scale.

You are right about going to fast is bad, but the longest time should be before the voting! Because discussions after vote-start can not result in a changed proposal, a new changed proposal and a new vote would be needed.

Have a look at political elections! The election campaigns begins several months before the election but the election itself is only held for one day! On OSM the best would be to have at least one months RFC-time and exact two weeks of voting time (like on Wikipedia). If the polling is too low enough it should be extended by one week until at least x (i.e 10) votes are collected. What do you think about that? --Phobie 06:03, 28 November 2008 (UTC)

Also I completly agree with your statement : "Time should be spent in discussion and RFC", the problem is however that reality of osm (and also maybe sometimes in real life) is that people are "lazy". In fact most of them don't even want to read a proposal until it is finished. (see the recent talks on the talk list). And since there is no status "finished" (or have I missed something ?) they just wait the mail on the list that says "voting". Aren't you surprise, that, on the Proposed_features/mtb:scale we have been 4 to discuss during RFC, and now many others are coming to discuss it ? The Proposed_features/mtb:scale is an easy case, the proposal is good and there are few controversory, however, if I take the Proposed_features/Smoothness we have had good objections during the 6 month RFC, we solved most of them and abandoned some on a trade-off. And then nothing evolved that much, so that's why you shortened the voting period, and you were right in a world where every one has taken the time to read it. Unfortunetly, this was not the case, a ~50 messages thread about smoothness on the talk list just started last week with dozen of good objections that we should have taken care of earlier.
  • The process has some drawbacks, I am thinking of many things to make it better, but they all have (huge) cons, so the easy one I am doing now is extending the voting period in a "test goal" to see if more people get involved. Other idea I have are :
  • put a feature on the map feature at "half way vote" to see what people that use it thinks (let's call it a approvement real life test period)
  • Send more email on talk to give advancement of the project OR voting process
As of you comparison to real life, the one day vote is IMHO a question of money and organisation, this has the drawback of letting people in holidays aside of the vote. And 15 days is a good trade-off, but I (and another, see the vote zone) have been de facto refused a vote on Status because I wasn't there. That's my fault because I didn't took attention on the RFC email on talk, but another one with "voting" would have took my attention.
For my last "real life" example comparison, in france, the only one day vote targets only "end user" the "we" on president election, deputies election. BUT not on law voting, and what we do here in osm, look much like a law voting. "Our" (I mean, our deputies) solution in france is to discuss a law during 2 month up to 10 years, make a one day vote on it. Submit it to another chamber (senators). revote on it 2 month later, if refused, start again. Even if approved, other votes of "correction" can re-happen later then. Sletuffe 10:57, 28 November 2008 (UTC)
Uh, you put out a lot of text! Some ideas on how to resolve your problems:
  • If you think you need to attract users to comment by starting the vote-period, do it but
    • the RFC-period should be at least 14 days and not 5 like on Proposed_features/mtb:scale
    • no changes are allowed above the votes on the proposal page!
  • If users have mayor objections and alternative solutions after the vote-start, start a improved proposal and link to it from the running vote or describe the modifications below the first-vote and start a second vote below that description.
  • Perhaps we should remove the vote-end-date and just check a running vote after 14 days.
    • If there is a clear result approve/reject it.
    • If there is a discussion running or less than 8 votes recheck a week later.
  • I think it is better to get acceptable results and improve them as to try to get a perfect solution on the first run (and fail).
--Phobie 12:22, 28 November 2008 (UTC)
Clever suggestions. I made an error on the mtb:scale stuff, if you read comments, I have done some efforts to make it last longer, but I've been pushed to move to voting by some people who had some good arguments to do so. My bad. For my defense, I would say the proposition was aged of more than 5 days, see Mountainbike history (a king of first version like you suggested). It was restricted to a german talk, but they did many work there for a rather long period. Sletuffe 12:37, 28 November 2008 (UTC)

Reunions Francophones/6ème Réunion

Sylvain, pourrais-tu mettre un peu d'ordre dans tes questions/commentaires sur l'ordre du jour de la prochaine réunion ? Parce que d'habitude, on fait le tour des questions une après l'autre et là, c'est un peu le bordel avec des questions barrées mais avec des commentaires. Par exemple, lier la ML et le forum. Il faudrait qu'on sache si la question est encore d'actualité ou pas. Si tu veux qu'on en parle, enlève la barre. Sinon supprime la question complètement. Merci. Pieren 17:01, 9 December 2008 (UTC)