changed 8 months ago  
Linked with GitHub

OSMF Operations working group meeting

Thursday 8 August 2024, 19:00 London time, unless rescheduled
Time in your timezone
Countdown
Online calendar
Subscription to future events
Frequency of meetings: every two weeks, on Thursday at 19:00 London time, unless rescheduled.
Video room

Participants

  • Grant
  • Tom
  • Sarah
  • Minh Nguyễn
  • Dorothea

New action items from this meeting

  • Grant to work on the builder for debian packages [Topic: apt.openstreetmap.org next steps?]
  • Grant and Tom to discuss apt.osm.org supports api upload [Topic: apt.openstreetmap.org next steps?]
  • OPS to evaluate Fastly Security (DDOS) Protections we could use. [Topic: Cloudflare / Fastly]

Reportage

Deployment of new production services

Related to action item 2024-07-25 Grant to move the requirements regarding deployment of new production services that were mentioned during the 25 July meeting to the ops site in a "Policy" communication format. [Topic: Deployment of new production services]

Grant added it to https://operations.osmfoundation.org/policies/new-services/

Cloudflare - Dealing with scrappers

Related to action item 2024-07-25 Grant to determine the Cloudflare API call to block IPs, in order to deal with scrappers [Topic: Cloudflare keep enabled?]

  • Grant has a script that he will share with Tom.
  • Cloudflare API: Easy to add addresses, difficult to remove IPs from a blocklist, as you have to get the ID of an individual block.
  • Fail2ban has a Cloudflare option for blocking an action.

Agenda

OSM.org Editor Inclusion Policy

TBC minutes summary of discussion (SDRP, "Best Interest", Appeal board.)

Outcome: It was proposed that the SDRP should serve as the appeal body for editor inclusion on www.osm.org and oversee the policy, ensuring that editor inclusion serves the 'best interest of the OpenStreetMap project'. A period for community feedback during the initial evaluation was suggested and the SDRP could be invoked by the OWG, board, editors, or the community, either during or after the initial evaluation of editor inclusion.

Minh Nguyen, from SDRP, presented some of the points he had raised via email to OPS, regarding the OSM.org editor inclusion policy.

Both Guillaume, who wanted to add to the OSM.org editor inclusion policy the requirement of editors to be under SDRP, and Paul, who was against it, were absent from this meeting. Minh offered to raise his points at the next OPS meeting.

On the proposal to have the editor inclusion policy mention the SDRP

  • This was proposed to ensure that editors act in the best interests of OpenStreetMap as a project. E.g. not have an editor that just deletes buildings.

Concerns relayed by Minh

  • The SDRP's role shifting from its original purpose. Initially, SDRP was presented to the community as a voluntary body that developers could opt into, with no pressure from the Foundation. The original mandate, agreed upon by the community, stated that participation in SDRP was not a requirement for getting OSMF funding.
    ** This was also Paul's position.
    ** There may be some flexibility depending on OSMF's decision. For example, there could be a mechanism for OWG to consult the SDRP either on an ad hoc basis or through a policy suggestion.
    ** The scope of SDRP could be expanded.
  • The SDRP is currently inactive. It was formally created for iD, but has never been used. While it could be convened if necessary, this is uncharted territory.
    ** One member resigned in November 2023. The board extended the terms of the remaining SDRP members.
  • There is community concern that this could be used as a backdoor to introduce features like AI.

Other concerns

  • External concern relayed regarding the policy to specifically exclude Rapid from being added to www.osm.org. They mentioned they were happy to disable default features and to adapt the editor to meet our requirements.
  • Contributions by editors added to www.osm.org not solely for the OSM project, e.g. the data is also provided to other commercial or semi-commercial projects.
    ** This could be addressed under "best interest."

OPS:

  • Want the decision about evaluating if an editor's inclusion to www.osm.org is in the best interest of OSM, to be made by others, as it's not their field of expertise.
  • Would like some way of measuring compliance to the policy.
    Point of contention: voluntary opt-in to the SDRP.

On who to draft the policy

  • The board is not the best body to write the policy.
  • The board could provide some input and OPS to draft the policy.

On who to make the decision for the addition of editors

  • A board decision may be preferable, as it impacts the entire project, not just OPS.
  • The decision should ideally be made by someone independent of the OWG.
  • If the board forms a committee, it may consist of the same individuals as the SDRP. Therefore, extending the SDRP's scope could be a more efficient.

Suggestions

  • Have the SDRP as an appeal board.
  • Edit the policy language.

Suggestions on the policy content

  • Policy has to have mechanism to revoke inclusion.
  • Suggested wording of policy: "SDRP can evaluate if the editor is in the best interest of OpenStreetMap, and if it's not in the best interest, they can ask the editor to change or they can ask us to remove it". OWG/community/editors can be invoked if the editors is in the OSM's best interest.

Suggestion to have SDRP as an appeal board

Suggestion: Make the SDRP the appeal body and and place the editor policy under its authority, not the editors, rather than under the editors, allowing the SDRP to handle both political decisions and potentially initial decisions within the policy.

  • If an editor disagrees with an SDRP ruling, they will be removed.
  • The SDRP can be invoked by the OWG, board, editors, or the community. For example, the OWG could consult the SDRP on whether a chosen editor serves OSM's best interests if any complaints arise.
  • On the addition of editors:
    ** Editors could be added, without necessarily OWG sending them to the SDRP.
    ** Suggestion: Introduce a sufficient time window, e.g., two weeks, during the initial editor evaluations, during which the addition of editors can be appealed. Appeals can also be made after this period.
    ** The window should be long enough to allow people time to appeal.

Other points

  • Should manage community expectations,as there were assumptions about the SDRP’s purpose.
  • The board will need to provide its opinion on the policy, and thus on whether to include SDRP or not.
  • The practical implications of being under the SDRP were unclear to maintainers, which is why no projects other than iD were subject to it.

On editors sending data also to other projects

  • It is in the best interest of the OSM project to remain the central repository of data and avoid leaking data to other projects under different terms.

Minh might join the next meeting.

apt.openstreetmap.org next steps?

Current packages were exported from launchpad and pushed into repo

Action items:

  • Grant to work on the builder for debian packages
  • apt.osm.org supports api upload, Grant and Tom to discuss

Cloudflare and Fastly

Cloudflare - Tor and other

  • Tor users affected by Cloudflare Capture, tor users have been "allow listed" from today as a workaround.
  • Cloudflare non-sticky backend causes issues during non-syncronised deployments. Deploys are currently manually synced to avoid this, but need to be resolved.

Cloudflare / Fastly?

Tom's preference for Fastly in long term.

Fastly:

  • Caching service.
  • They have some rule sets for doing rate limiting per IP address with a small window.
  • With the current product we don't have evaluation of an IPs reputation and information about faked user agents.

Cloudflare:

  • Denial service protection service with caching.
  • Might be problematic turning them off - would have make sure that all three machines deploy at more or less the same time, to not end up with desynchronisation.
  • Purge - single API call.

Action item: OPS to evaluate Fastly Security (DDOS) Protections we could use.

Open Ops Tickets

Review open, what needs policy and what needs someone to help with…
https://github.com/openstreetmap/operations/issues
https://github.com/orgs/openstreetmap/projects/1
https://github.com/orgs/openstreetmap/projects/1/views/2?filterQuery=-is%3Aclosed

Action items

~~* 2024-07-25 Grant to move the requirements regarding deployment of new production services that were mentioned during the 25 July meeting to the ops site in a "Policy" communication format. ~~[Topic: Deployment of new production services] - 2024-08-08 update: Added to https://operations.osmfoundation.org/policies/new-services/

  • 2024-07-25 Grant to determine the Cloudflare API call to block IPs, in order to deal with scrappers [Topic: Cloudflare keep enabled?] 2024-08-08 update: Briefly discussed
  • 2024-07-25 OPS to make a reasonable evaluation whether to go with Cloudflare, Fastly or none. [Topic: Cloudflare keep enabled?]
  • 2024-07-25 Paul to follow up with Copernicus and see if we can get rendering servers from them. [Topic: State of the Map Europe 2024]
  • 2024-06-27 OPS to do capacity planning for tile.openstreetmap.org [Topic: rhaegel usage?]
  • 2024-05-02 OPS to revisit the OpenMapTiles application. # 2024-06-13 They haven't responded to the questions. Paul to email them again. # 2024-07-25 They have replied, OPS haven't had a chance to look at the answers.

OPS pads for 2024 meetings

Minutes published on the OSMF website

Automatic addition of OPS meetings to your calendar

If you want future OPS meetings to be automatically added to your calendar,
you can subscribe to the following iCalendar link. Instructions on how to do
that depends on which calendar software/service you use. The link is provided
for your convenience.

Note that:

  • This might not work when Framasoft servers experience problems.
  • You might get delayed updates, depending on how often the calendar service
    from your side syncs/checks for updates.
Select a repo