Board/Minutes/2018-10-18

From OpenStreetMap Foundation

Draft minutes
Location: Mumble, Thursday 18th of October, at 21:00 London time

Participants

Board members

  • Peter Barth (chaired the meeting)
  • Heather Leson
  • Mikel Maron
  • Paul Norman
  • Frederik Ramm

Biographies

Guests

  • 7 guests.

Open to all OSMF members.

Guests are welcome to speak at the end of the meeting on the topics that have been discussed. Please note that text messages sent on Mumble chat may not be seen by people who join using mobile apps.

Not Present

  • Martijn van Exel (Apologies)
  • Kate Chapman (Apologies)

Administrative

Previous minutes

Circular Resolutions

None.

Previous action items

Name Date Action item and status
All 2018-03-15 to send a reminder about etiquette guidelines on osmf-talk, talk & facebook page.
All 2018-02-15 to clean-up the SotM draft policy document.
All 2017-11-16 to send an email to members, months in advance of the 2018 Annual General Meeting, encouraging them to discuss and perhaps propose their own resolutions.
Frederik 2018-09-20 to update Roland Olbricht, maintainer of the Overpass API (downstream data controller).
Frederik/Paul 2016-05-28 to prepare transparency document from transparency session.
Heather 2018-09-20 to draft an email to the working groups about identifying potential risks and share it with the board.
# Done
Kate 2018-02-15 to follow up with Grant about the technical workaround of having conference announcement banners on osm.org linked to landing pages on the website.
Kate 2018-01-18 to update the etiquette and add a reporting plan.
Kate 2017-08-24 to write to the Advisory Board members about microgrants.
# Done
Martijn 2018-06-21 to initiate discussion on the osmf-talk mailing list about refining the Local Chapter criteria.
# Suggested period for discussion: two weeks.
Mikel/Paul 2018-03-15 to look at the ten most active mailing lists and see if people listed as admins are active in the moderator role, what is in place, and how they manage the lists.
# 2018-05-24 Mikel drafted email and both agreed on some modifications.
Mikel 2017-08-24 to send email on the list to find businesses that would like to offer input on the Welcome Mat.
Mikel 2016-08-19 to send round bullet points on diversity policy proposal.
Paul 2018-04-19 to document the evaluation process of software and services used by the OSMF. Related to our FOSS policy.
Paul 2017-02-21 to separate the State of the Map (SotM) net profit discussion items and start the follow-up discussions.
Paul 2016-10-28 to create a page on the wiki, listing software products which are used by OSMF and are closed-source and/or are externally hosted.
# Was Peter's
Peter 2018-09-20 to draft email to start off discussion on the osmf-talk mailing list about developing guidance for our involvement in politics/activism.
Peter 2017-04-18 to make a list of requirements for email self-hosting and discuss them with the Operations Working Group.
Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

Board election / Annual General Meeting

AGM date

The 12th Annual General Meeting of the OpenStreetMap Foundation will be held online in the IRC chat room #osmf-gm on the IRC network irc.oftc.net, at 16:00 UTC on Saturday, 15 December 2018.

Suggestions

  • Community questionnaire
    • Community lists out questions, which are then compiled by a person who is considered trustworthy, and presented in an organized way. We have asked Michael Collinson if he is willing to help (post-meeting addition: Michael has accepted).
    • Candidates submit answers and their manifesto in private to the selected person.
    • Simultaneous publication of the answers.
  • Discussion: have a defined period for discussion.
  • Potential timeline: https://teamup.com/ksc2ex6bcwceu3aqez

AGM date and timeline

  • Last years: AGM on 5th-10th of December.
  • Notification timelines depend on if we are putting out special resolutions or not.
  • 4 weeks in advance of the AGM is in excess of all notification timelines.

Process

  • Any process that we put out must be accepted by the community.
  • The board should not have strong influence on the process.
  • Michael Spreng (MWG) is willing to help.

'Next steps

  • Decide on who will step down and who will stand again for election.
  • Decide on the process and publish it.

'Decisions

  • AGM: 15th December.
  • 4th November - end of internal discussion on how to proceed.

Other points mentioned during discussion:

  • Make sure there is enforcement of etiquette and kindness.
  • If people have ideas that are problematic or are racists, we should be able to call people out.

Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

Questions on organised editing guidelines

Guillaume Rischard (from the Data Working Group) attended this meeting and answered questions about the organised editing guidelines' document, which is a new version of the former draft Directed Editing policy, written after the feedback the DWG got.

Please note that questions and answers are not presented verbatim.
Bullets: questions or comments from board members.

Hash tags

  • The guidelines talk about "hash tags" and make the "hash tag" part of the changeset comment. Can we change the wording so that "hash tag" can either be a part (a special string) of a changeset comment or a real tag, as in the changeset hashtags (much as iD already does it)?

Guillaume: We can just say that the hash tag can be part of the changeset and be done with that.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Guidelines contain prescriptive statements

  • Concern expressed that even if the document is guidelines, not policy, there are prescriptive statements in it. We need to make a clear choice if it is a policy or not. Penalties and enforcement of rules need to be in a policy, not in a guidelines document.

Guillaume:
- The DWG is going to enforce them just as it enforces anything else which comes from community consensus.
- There are many things that we have that are just guidelines - for example that you should have proper changeset comments - and we enforce it anyway. We enforce what the community consensus is, and if this is the community consensus then this is a good thing, this is how want organised edits to proceed. Then we do the same as with the other texts.
- We put in the text that the DWG can intervene for the sake of clarity - no other reason.

  • When it comes to enforcement, this is not a problem with just this policy: recourses are not necessarily enforced - we kind of have to decide on what the lines are. Even if it is a guidance, it should be clear what are the steps to mitigate the problem or to resolve the issue and how to deal with feedback.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Appeal process

  • What is the appeal process? How do we guarantee transparency?

Guillaume: We have the board, elected by the community and directly accountable to it. If someone is not happy with what the DWG does, the next step is to you. Maybe have a general document from the board which says if you are unhappy with somehing that a WG has done, then people can contact the board.

  • The ban policy explicitly states that we have an appeal process.
  • 3 appeals to the board so far, which were unsuccessful.
  • Later on we might want to document appealing all WG decisions.

Guillaume: Current documentation is fragmented. Making it to something elegant and clear takes a lot of work and volunteer free time. Something that we should try to achieve but also consider its cost.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Communication channels

  • 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.
  • Related comment: These requirements would prevent people from having dinner together!

Guillaume: It is not intended to prevent people from having coffee together or never having a private discussion- that's one of the joys of contributing to OSM, that you meet wonderful people. "Good faith" is a phrase that comes in the guidelines a few times. It means that you do your best efforts to have the conversation in public. People can have coffee together and then send an email to the local mailing list saying "that's what we discussed and that's what we decided" - that's fine as well. The public record should reflect how decisions were made.

  • The guidelines say "all related communications should use channels that are open (no non-OpenStreetMap registration required), public, and archived". Many communities use communication channels regularly outside the forum, mailing list or wiki. This is advocating against what is in current practice by a lot of communities. How do we rectify that issue?

Guillaume: The document says communication should be open, archived. It should be - it doesn't have to be. If a local community says that Telegram is wonderful, then that's fine. It is open - you still need to make a login, but this is a compromise you need to make. No one is going to be absolutely mad at you if you communicate with the local community on Telegram, because the community decides to use it.

  • A lot of communities is Asia use Facebook and Twitter to communicate. Those are not necessarily open channels but they certainly do sometimes work with open principles: the community is welcome to join the physical group. As long as it is flexible to recognise the diversity of local communities into how they wish to communicate, that's fine.
  • We have harder guidelines in place, like the import guideline, which forces you to at least announce your plan to the import-mailing list. This soft requirement with "should" it is very contrary to the openness we have.

Guillaume: It was written in that way on purpose, because we wanted it to be applied as widely as possible. It is rewritten as a "best effort" - try to do these things. Not following them is not an offense per se. It is really if you did edits, and were problematic, and did not follow the guidelines at all - then enforcement is going to be there more quickly.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Scope

Current phrasing in the document:
"The organised editing guidelines apply to any edits that involve more than one person and can be grouped under one or more sizeable, substantial, coordinated editing initiatives. While primarily aimed at map editing, they can also be applied to other aspects of the project, e.g. the Wiki."

  • 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. Essentially, a lot of what this is saying is that there is some responsibility that editors are seeding to someone else in the community.

Guillaume: This was considered and we spent a lot of time on the scope, trying to get it just right, not to create any perverse incentives. In this case it could create a perverse incentive for no one to take responsibility. "If we have someone who is responsible then we have to do all those things, then let's not do them and say no one is responsible. It is just a few users doing something at this big company. Having someone responsible? No, we have no one like that." We did look at ideas like that, only applying to something co-ordinated, but then it is encouraging people not to coordinate. So, this is why, in the end, we discarded this kind of setting in the scope.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Documentation of individual activities on the wiki

  • Have you looked at the current practice by most organised editing teams? I haven't heard too much issue with what is currently done for individual activities. I understand the need of having a single compiled list of all the entities which undertake activities but right now the standard practices is not to create separate wiki pages for all of them - and wiki would be hard to use anyway. Current practice seems to be working well and we could adapt the documentation to what is already the best practice. A lot of organised editing teams have Github repositories where activities are listed (e.g. Apple, Mapbox, Telenav).

Guillaume: The issue is that these disappear. We have no guarantee that they will be there forever. What we could do certainly is have a form, so they fill out the form and we will also provide examples. But it is important for things to be central, even if it is just copy/pasting and changing the text of the title, the activity and the place and the rest stays the same. The wiki is the only guarantee we have that it will be forever accessible by the community.

  • I had some problems with stuff going on the wiki, because you can't search it, unless you know exactly where to look already.
  • Internet solvable problem -just push technology. Whether it's on a Missing Maps events page or a github account, find a way to push it to the wiki, sounds like an activity which needs to happen in order to support the recommendations to go out.
  • It wouldn't be our responsibility to provide the mechanism to push into the wiki the information from their internal activity tracker. If someone wants to use a different mechanism for internal tracking and then either themselves or with the help of the community, feed that to the wiki, that's fine.

Proprietary information

  • 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”. That's best practice for sure but there may be some proprietary information which can't be shared. Sometimes -not often- this could be a situation you cannot get around. This could be about training material or internal employee documents, which could only be tangentially related. How do we allow for things that may fall out of this and may not be publicly shareable?

Guillaume: Having explicitly an exception for that would be a perverse incentive to make everything proprietry. Guidelines, best effort - community may or may not object. We also tend to be unhappy with people in general (whether they are organised or nor), if they map from a source that other mappers can't check. In the end - in the discussion with the community, in the documentation of the wiki - if there's good, legitimate reason for this document that the team is going to have -if there's a good reason to not share it- then why not? It's up to the community.

  • If people are creating training material, one of the things that happen with other communities is that they give back. So, if they have internal training material that taught them how to improve their processes, more often than not people would open them up. If you found a better practice of how to validate, then that's a good thing to share. With any guidance document you can encourage people in terms of how to implement it.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Timelines for communication

  • What about situations where something is announced and discussion ends after a short time? What is the need for keeping something open for a full two weeks? Likewise: 2 working days for replying to a message is a pretty short, if someone is on a flight. Maybe meeting in the middle on both of these would make a more reasonable timeline? One week for announcement until commencement. There's some ambiguity about punitive methods attached to this. It would be good to consider the operational realities.
  • Problem if people do not respond but continue to edit - they are obviously available. Maybe we can work-in the fact that it is not really business days but if it is possible for them to respond.
  • I know that we are not talking about emergencies. Restraining people for 2 weeks - having run mapathons with a week's notice- is a bit tight. In terms of 2 days, I think we have to say "up to 2 days". The restrictions of the time maybe does not reflect the ever-changing nature of the mapping community around the world.

Guillaume:
- If you do a mapathon on short notice and is not controversial, then everyone will be happy with it and will fall within "reasonable time" ("The community should have reasonable time to discuss"). We also have an exception for humanitarian mapping and again "best effort". And sometimes the community is going to want to discuss this for longer because there are issues, so 2 weeks is going to go out of the window.
- 2 days: we got that from the vandalism guidelines (give people 24-48 hrs to respond). Waiting for 1 week for people to respond every time is too long.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Punishment

Guillaume: Regarding punishment, actions may happen for edits that are problematic, but not following the guidelines per se is not an offense. So, if you make this fantastic edit and you did not follow some bits of the guidelines, that's not a big deal.

Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment

Decision

Voting is deferred to a circular resolution.

Heather had to sign off (60').

Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

GDPR preparation update

Request for proposals

The list of API calls that need changing due to GDPR is here. Some of them have already been done by community members (thanks!). The OSMF will look for person(s) to prepare pull request(s) for acceptance against the current "openstreetmap-website" code that will implement any changes that have not been done yet. A draft request for proposals has been prepared.
  • CGI-map: partly done by one user, but still needs work so should be included in the request for proposals.
  • RfP: ready to be posted.
  • Suggestion: have an assigned person of contact, for people who will implement the suggestions.

Decision: The draft request for proposals will be published on the dev mailing list and on osmf-talk.

Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

Advisory Board - monthly update

The Advisory Board members are separate from the OSMF board of directors - individuals are either nominated by corporate members of the OSMF or invited directly by the OSMF board of directors. The OSMF Board of Directors will publicly minute, in the board meeting minutes, any communication sent to, or received from, the AB members. This monthly section is reserved for this purpose. Overview.

AB related updates and board discussions:
2018 Sep, Aug, Jul, Jun, May, Apr, Mar, Feb, Jan
2017 Oct, May (F2F), Apr, Mar, Feb, Jan

Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

Any other business

Documenting the guidelines Q&A session

Decision: will be included in the minutes.

Next steps for organised editing guidelines

Points mentioned during discussion:

  • Mikel and Martijn won't vote, but Martijn should have a chance to read the answers.
  • First circular resolution where some people can't vote.
  • Process: If people who do have a conflict want to vote they can say so, then there should be another vote first of the rest of the board members, ok'ing them to vote.

Decision: Wait for a reply after Martijn returns, so that he has a chance to read the answers, and then start a circular resolution.

Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

Guest comments or questions

Guests are welcome to speak at the end of the meeting on the topics that have been discussed. Please note that text messages sent on Mumble chat may not be seen by people who join using mobile apps.

Discussion about the organised editing guidelines on osmf-talk

Nakaner: Do I understand correctly that there won't be any discussion on osmf-talk or talk mailing lists on the organised editing guidelines?

  • We can not tell people what to discuss.
  • There is no plan to put out a proposal for people to comment on.
  • DWG has done a lot of discussion and the organised editing guidelines are what came out of it.

Have the board members been pushing the guidelines to be less restrictive?

Tordanik: Most of the questions about the guidelines were in the direction of whether they should be less restrictive than they already are in the latest draft. Is it safe to say that members of the board have been pushing it to that direction or where does this bias in the questions comes from?

  • The directions of some of the questions were about recognising the operational reality of the way the community and organised editing functions.
  • The differences between the current and the previous document are not due to board feedback, they are due to the consultation the DWG did (there were no changes to the current draft, after it was sent to the board).
  • Some of the board members are not entirely happy with the direction it got with not being a clearly enforceable policy, but recognise that it is a compromise that came out of the DWG. All 3 board members who are part of the DWG (Frederik, Peter and Paul) would probably like the policy to be stricter in regulating organised editing but in their DWG work they were part of the group that had to try to find a consensus and presented this work to the board as a consensus. They would potentially ask why isn't there less freedom to do organised editing, but as they have been part of the proces in coming up with the document, they don't ask these kind of questions - thus this impression is created.

Topics: Election and AGM | GDPR update | AB update | Q&A on OEG: Hash tags | Prescriptive statements | Appeal | Communication | Scope | Documentation | Timelines | Punishment | AOB: Documenting Q&A | Next OEG steps | Guests: Public OEG discussion | OEG and potential board influence

Next meeting

Meetings take place on the 3rd Thursday of the month, at 21:00 London time, unless rescheduled.

The next monthly board meeting will be on the 15th of November, at 21:00 London time, unless rescheduled.

Meeting end