Preface
I created this template to aid project co-ordination in tasking managers, and contributors seeking feeback. It has gone through several iterations; this is the one that I currently use. I think that there will likely be some alterations, because I see some potential impovements, though I haven’t yet received feedback regarding it from mappers.
Following interest in the template I use for validation comments from other validators, I am going to share the current version I use in this diary entry.
Please, try it out and share your ideas, experiences, and results.
The template is formatted using Markdown.
Thank you to anthaas for the idea of publishing a diary entry about it.
My experience is in using the HOT TM so there may be some idiosyncratic parts which should be modified to be accurate/function within whichever TM is being used.
I have not yet seen what if any impact this has on 3rd pass validation.
Design Rationale
It was over two years ago now that I (in)validated my first tasks on the HOT tasking manager. I took a break from that until ~ 7 months ago when I started validating some more tasks here and there. Then ~ 4 months ago SColchester put me onto a good project for a beginer validator, and after that I was validating tasks at a significantly greater rate. It was also his comment on a previous diary entry of mine that insired a change in this temlpate.
After (in)validating a greater number of tasks via the HOT TM, I soon found that I was repeating myself quite a lot. For instance, linking to learning resources, events and thanking users for their contributions was very standard. I didn’t exactly fancy writing the same thing over and over, and I wanted to reach more contributors, so I decided to create something that’d make the process more efficient and idealy result in a higher quality of contributions.
The HOT TM comments section supports markdown formatting, so I decided to apply the skills I’d aquired while improving the formatting of the MMLWG FTOTW & Mid-Month Mapathon OSMCal listings, to create a standard validation comment template. This template would include a standard message, along with space for tasks specific comments and contributor feedback.
A clear distinction was made between the feedback that I was giving to a contributor, or contributors, and the reason(s) why I (in)validated a task. This is because the two may or may not be related, and I wanted to create something that was easy to reference for contributors who go on to complete an invalidated task, and for future validators.
Fig.1. Annotated Screenshot Example
There was a time where I would make annotated screenshots, and post them on tasks (with a legend) to provide visual feedback, however at some point I figured that if I’m going to be pointing to and drawing features; I might as well just map and upload them, so I have since transistioned to using OSMCha. This works well, but some things are irrelevant in changeset comments and verifications. For example, It often doesn’t make sense for me to submit changeset comments about what wasn’t mapped. Even if a task is not complete, the contributions themselves may be of a high quality.
A significant proportion of regular users who contribute via the HOT TM do not know how to access a task’s changesets, nor use OSMCha. Given this, and that feedback will also be provided to absolute beginers I saw it necessary to add sentences directing users on how to access it.
Given that mappers contribute on a voluntary basis, that tasks and projects are not homogenous in density of features, or difficulty, and that validators can multi-task validate. I decided to add text about splitting tasks, becasue projects make more continuous progress by ‘locking it in’ if a smaller area is submitted after being well mapped, as opposed to a larger one that would later be invalidated. This would probably be better located in the project instructions or completion panel of a task, so that initial contributors are aware of this option.
I wanted all of the users who contributed to a task which was later (in)validated to be notified hence “#contributors”.
Adding a link to Nicolelaine’s Continuing you contribution web page to this template could also be a good idea (especially when validating via the HOT TM), becasue it contains many HOT related links and explanations. The short URL also lends itself well to being added to a changeset comment, given the character restriction.
The Template
Appearance
Validation Feedback
@someone Feedback feedback feedback, feedback, feedback.
Reason(s) for (in)validation (generally not exhaustive)
- Reason 1
- Reason 2
or reason 1. reason 2
Before attempting to map an invalidated task, or for feedback:
- Check the project and task comments.
- View the task change-sets via task data in top right of the task window.
- View an entire validated task, by lodaing the data in an editor via the task window.
If you cannot complete the entire task, either due to time constraints or your ability, then it may be a good idea to split the task: you don’t have to do it all yourself, nor all in one go.
Thank you for your contribution. #contributors
A mapping event is hands down the best way to recieve feedback and interact with other mappers. Here’s one that occurs regularly.
You can find other events here
Learning resources and links can be found here
The Code
# Validation Feedback
## Reason(s) for (in)validation (generally not exhaustive)
-
## Before attempting to map an invalidated task, or for feedback:
- Check the [project](https://tasks.hotosm.org/projects/PROJECT_ID#questionsAndComments) and task comments.
- View the task change-sets via task data in top right of the task window.
- View an entire validated task, by lodaing the data in an editor via the task window.
If you cannot complete the entire task, either due to time constraints or your ability, then it may be a good idea to split the task: you don't have to do it all yourself, nor all in one go.
Thank you for your contribution. #contributors
---
A mapping event is hands down the best way to recieve feedback and interact with other mappers. [Here's](https://www.tickettailor.com/events/missingmapslondon?) one that occurs regularly.
You can find other events [here](https://osmcal.org/)
Learning resources and links can be found [here](https://wiki.openstreetmap.org/wiki/Beginners%27_guide)
Usage
Copy the code and ensure that the first line is empty, then save it as the master validation template file (I use notepad). After you choose a project to validate substitute the project ID for “PROJECT_ID” in the template. Currently this seems to only send a user to the project page and not the specific section, but maybe the functionality could be improved in future.
You can also add project specifc tips or cautions in the ‘Before attempting to map an invalidated task’ section, e.g. ‘beware the primary imagery source is off-nadir which means that you can see the Eastern walls of buildings; take care to not include the walls of a building in its footprint.
Then just copy the code and paste it into a markdown supported text box, add task/user specific feedback, then submit the comment.
You can then save this as a project specific version of the template, or just close the template without saving after validating.
A template like this one works well in tandem with a tool like peculiar theater’s crib sheet, becuase it provides structure and formatting to the task/user specific comments you provide.
Even if you don’t provide any feedback as a validator, posting this template in the comments can still help contriutors obtain feedback by viewing task changesets to see the changes you’ve made, or by guiding them to alternate sources. Good changeset comments can help others to understand your contributions.
If a task should need to be invalidated again, then probably only the validation feedback and and reasons for (in)validation need to be posted, as to not take up space in the comments with redundant information.
Edit 1: Added (I use Notepad).
Edit 2: Added split task paragraph in the Design Rationale section