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.

… See full entry

Today I realised that it’s probably significantly more efficient (in terms of effort and time) to simply state the reason(s) for (in)validating a task in the task comments, and ask contributors to read the project comments where I can post some more detailed comments, explinations, pictures etc. related to common mistakes I find while validating the project.

This efficiently accomplishes at least four objectives;

1. Contributors who read the comments recieve feedback regarding their contributions
2. It is easier to get an overwiew of quality issues in the project.
3. It saves time in comparison to giving feedback on each individual task.
4. Contributors to the project who map areas yet to be mapped and read the project comments can get a heads up, before contributing increasing the likelihood that they will avoid making the same mistakes.

Farewell to giving feedback on every task, unless it is truly unique. 😌