Process -- done, discussed with local community, decided that the data we collect is of public value and should be added to OSM.

Step 1.
Gain familiairty withe the basics of OSM -- done, long ago.
Revide what can go wrong with imports -- read.
Identify data you'd like to import -- done, it's trees.
Be aware of OSM licensing -- done, aware.
Review the import guidelines fully before beginning -- reviewed after I was pointed to them.
Contact the community -- done, interest was there.

Step 2.
Must obtain proper permission from the owner -- done. Users agree to make the data they collect public domain.

Step 3.
Documentation -- done after I was pointed to.
Wiki page with outline not created. Information on converting the data, dividing the work, handling conflation, mapping GIS attributes to OSM tags -- not applicable. I can create a page if absolutely necessary, but it would be of little actual value.

Step 4. Community buy-in.
Done.

Step 5. Import review.
Not applicable. No such thing as "data completely prepared and documented" as users are adding data on the go as they find it.

Step 6. Uploading.
Not sure how this is applicable. "Let everyone know when you're done" -- not applicable. Provide updates on efforts -- makes little sense, like, post daily digests? I don't understand how this should work.

Key considerations.
Discuss your proposed import -- discussed with the local community.

Document your import -- done on the organized editing activity page.

Use a dedicated account -- done, only doesn't have the "_import" suffix since it's not exactly an import, more a continuous exchange.

Use the right tags -- done, all documented.

Don't put data on top of data -- I don't understand, likely not applicable.

Take great care to avoid damaging the database -- done. We only add/update nodes of specific types (trees), not doing anything complex, so hard to damage anything.

Yes I have created the wiki page after I was pointed to that requirement, as a sign of respect. I did discuss this with the local OSM community and they have no issues with our activity.

Also, I see in the organized editing guideline page the following text:

> The Data Working group will intervene for edits the community has issues with, and [we] will not intervene for merely not following the guidelines.

Do you think there are issues with edits in this changeset? We added species, height and a couple more attributes. What exactly is wrong with this?

Regarding the Import/Guidelines, I did read that and follow it, the only missing part is the discussion in the global mailing list and a comprehensive import plan description. It's missing because we don't have an import plan because this doesn't actually look like an import. The guide suggests in multiple places that this is rather about importing huge amounts of data, e.g. a cadastre decides to share all their data. This is suggested with phrases like preparing a file with data before importing and sharing on Google Drive.

I'm not sure if this is really needed for our case? We collect like one hundred trees per week currently. Is there a way to handle this with a little less bureaucracy?

#YerevanTreeMap

testing if comments are linking

We did create an Organized Editing Activity page in the wiki, it includes a description of how the process goes: osm.wiki/Organised_Editing/Activities/Yerevan_Tree_Map#Import_plan

There is no dataset to import per se. We had around 4k trees in our local database and they are already in. We want to send updates from now on, e.g. people with an app collect new data, on tree heights etc, and we send that data in small changesets, up to 100 nodes per hour. We usually do weekly mapping sessions with a couple of volunteers, so there's not much data expected. Do we still need a complex import plan described for this, with revert plan etc?

OK