ChaosPad V1.1
Full screen

Server Notice:

hide

Public Pad Version 294 Saved Oct 12, 2018

 
Questions regarding the Organised editing policy
 
  • Peda: Can we have a slight change in wording so that "hash tag" does not necessarly mean to be a special string in a changeset comment but could equally mean a seperate tag in the changeset (much as iD already does it)?
  • Martijn: My most fundamental concern is with the status of this document. It states it’s guidelines not policy, however, there are prescriptive statements in there (if you do / don’t do X, you may be banned / activity may be stopped). I think we need to make a clear choice: either it is a policy or it isn’t. Penalties and enforcement of rules need to be in a policy, not in a guidelines document.
  • Martijn: A related an equally fundamental concern is related to that enforcement. If there are punitive consequences to certain actions, there needs to be clear and transparent process. Who decides if an action is in violation of the rules, is that decision and its process openly communicated, and who gets to enforce punitive measures? What is the appeals process? How do we guarantee transparency?
  • Martijn: Finally, I see the benefit in encouraging using existing / open channels to communicate around editing initiatives, but we should not prescribe local groups / communities / organizations how to  communicate. The current draft does not recognize the richness / diversity in communication styles and channels OSM uses, and I think it must.
  • Mikel: First, I’m happy for the progress made on this document. This strikes a good tone overall, and is certainly needed in our community. Do have some specific feedback and questions in the details of the document.
  • Mikel: “Guidelines” already have an established meaning from the ODbL Community Guidelines, and they are different in their enforceability status than this document. Can we consider calling these “Recommendations” or “Best Practices” rather than “Guidelines”? 
  • Mikel: The scope is a little confusing as written. A more comprehensive way to formulate it is as any situation where one (or more) contributor is taking community responsibility for other contributors — such as in a corporate data team or classwork assignment. Some mapathons might fall under this definition, but certainly not all. 
  • Mikel: Documentation of each team in a basic way on the wiki is a good practice. This means we will have comprehensive transparency on each team, and is the standard practice now. What is operationally challenging is listing every single activity on the wiki — many people across our community find extensive wiki editing frustrating. Currently organized teams make use of a number of tools to publicly communicate their activities, and it’s worked fairly well. Can we adapt this to current practice, and require solely links in the wiki to an activity tracker, so long as it’s publicly viewable and commentable?
  • Mikel: The bullets on “links where the community can access any non-standard tools or data sources used” and “if participants will receive training material or written instructions, a copy of, or link to, these materials” may drift into some proprietary information — such as a data source cleared to use in OSM, but not sharable, or internal employee training to a company. While sharing of sources and training materials should be encouraged to the greatest extent possible, when not, can a description of those things suffice?
  • Mikel: In communication with the community, these requirements would prevent someone from having dinner together! Transparency is important, but we all have personal discussions among ourselves from time to time. What’s important is that anything substantial to the community discussed privately is shared with others. Can we add some flexibility here, perhaps by asking that any private discussions report out later?
  • Mikel: The two week timeline from announcement to activity seems sometimes reasonable, but not always. What if an activity is non controversial and discussion ends after a short time? Waiting for the full two weeks seems overly strict in every case. Can this be framed without such unmovable timelines?
  • Mikel: Likewise, two working days for replying to any message is sometimes reasonable, but not always. What if someone is at a SotM conference, and can’t check their messages frequently until they get back home? If a timeline must be set, let’s make it the same for both discussion on the activity announcement and responses to community messages — say 1 week?
  • Mikel: Ignoring justified criticism and pressing on regardless can, however, lead to an activity being stopped and reverted.” is in conflict with other parts of the approach of the document. Who is to say what is justified or not? Who is empowered to stop and revert activities?
  • Mikel: The “What NOT to do” listing seems like a short and unusual list, and not specific to organized editing. What we are saying here is that anyone should abide by the community practices of OSM in general. Is there a better more general reference for community behavior expectations we could point to, that applies to individuals and organizations alike? Same goes for “Possible actions” — this doesn’t differ from what we expect from anyone else working in OSM, can we simply link to our standard community guidelines?