search

hotosm / osm-tasking-manager2

Designed and built for Humanitarian OpenStreetMap Team collaborative emergency/disaster mapping, the OSM Tasking Manager 2.0 divides an area into individual squares that can be rapidly mapped by thousands of volunteers.
http://tasks.hotosm.org
Other
425 stars 156 forks source link

Templates for project creation - instructions and other project attributes #172

Open pgiraud opened 10 years ago

pgiraud commented 10 years ago

I think a good strategy here is to decide on formatted templates for jobs, and then in job creation/editing, provide a form to fill in. This will make it easier for everyone to have quality looking jobs, while also keeping jobs secure and attribute data simple, as markdown.

AndrewBuck commented 10 years ago

I really like this idea, writing TM instructions is one of the most time consuming parts of managing a large activation, and trying to keep them current across multiple jobs can get very ugly.

The other advantage of having a more "form based" approach like this is it opens up the ability to filter jobs based on certain criteria, for example users who only want to work with Bing imagery, or who don't know how to set offsets correctly, etc.

My suggestion for an initial set of fields would be to look at the more recent jobs created on the ebola activation. We have been using the grey box at the top for common stuff, and then a standard format for the instructions as well. That should give you a good set of fields to start with and then we can modify/expand the list from there.

pgiraud commented 10 years ago

@AndrewBuck Something like https://github.com/hotosm/osm-tasking-manager2/issues/84 ?

AndrewBuck commented 10 years ago

Yes, requesting org would be one. But there should be other ones as well. For example we already have an imagery and comment field, but no source field. It would also be nice to have the instructions boxes broken down to be a bit more fine grained, but this kind of overlaps with the 'job template' idea so it is hard to know exactly how to proceed on this.

The reason I say it overlaps is, for example, you could split the instructions box into multiple boxes, like one for what to map, another for how to tag the things that are mapped, etc. However a lot of these would be kind of standard answers anyway, since many jobs are a common format, so it would be good to either have these as templates for a single box, or the multiple boxes as they are worked out. We almost need to have a kind of brainstorming session on IRC or mumble to go over this with the various people who use this most often to come up with a good idea of exactly how to arrange all these.

jaakkoh commented 9 years ago

It would be good to get started with listing types of templates needed and as importantly vetting through existing tasks looking for a listing tasks with good descriptions as discussed in triage. Having an easily accessible list of good task descriptions for different types of tasks could be almost all we need on this?

althio commented 9 years ago

There are some good ideas very close to this issue in #427 'task templates'. This form/template could also include #83 required mapping experience; and certainly it would need to introduce other fields in the database. As an added bonus I guess such a form/template would later make instructions easier to maintain and translate.

Let me propose a draft... This is the kind of form the project owner could start with. Only the items ticked at creation would be used after the project is launched. We could use them for instructions, filter, checklist for complete tiles and checklist for validation #14 #421...

General

changeset comment field: from project id/name source field: from imagery

Experience/difficulty (scope of project, not individual tiles), general requirements and skills

Tasks - mainly ways

Tasks - mainly nodes/areas

end of draft

pierzen commented 9 years ago

This type of selection might satisfy some editors, but we should not force a rigid template with no flexibility. Templates, I see it more as sections you can select. Not as forcing me to add a series of element, selecting a category in it.

bgirardot commented 9 years ago

I agree with pierzen, but I also love the idea of what althio mocked up above.

For a lot of projects, just selecting from that list and having it pull in pre-written, clearly formatted instructions, in multiple languages, would cover the task well.

But I am fairly sure that no one is talking about removing any of the "free form" fields project creators can use now, but that a selection list like althio shows would be in addition to the free form fields. Selecting from the list would just basically "pre populate" the free form fields we have now.

I would love to see the actual instructions for those items in the osm wiki, with multiple languages for each set of instructions. Clicking on any of the check boxes would just go to the wiki, grab each language version of the instructions for that item and insert them into the project creation form for each language that was available.

This would let us refine the instructions and make it easy for anyone to review the instructions outside of the tasking manager and add a translation of the instructions for that item. And it would keep the text of the instructions for each language out of the tm2 code base where they would be much harder to maintain, adjust and translate.

If you check a box for an item that doesn't have instructions in the wiki yet, you would just get a notice that the wiki did not contain any text for that item, please write the instructions yourself and when done please add them to the wiki for next time.

And of course, if a project creator doesn't want to use the preset instructions, they can check the box, get the default from the wiki and then edit it on the project edit screens as they wish, or not check the box at all and just write or copy/paste their own instructions.

EDIT: I also understand what Jaakkoh is saying as well and I think we could get started down the path to pulling in pre formatted and translated instructions just by creating a wiki page in the HOT name space and putting in what we think are good, generic instructions for common things like roads, buildings, residential areas, which project creators could draw on right away, before any changes to TM2 code.

MarkCupitt commented 9 years ago

Keep in mind that instructions are very much related ot the activation in progress and change depending on the needs from day to day. Much more useful to be able to create a new project form an existing project .. and a lot more accurate in terms of the activation in progress.

Regards

Mark Cupitt

"If we change the world, let it bear the mark of our intelligence"

See me on Open Street Map https://www.openstreetmap.org/user/Mark_Cupitt

See me on LinkedIn http://ph.linkedin.com/in/markcupitt

See me on StackExchange http://gis.stackexchange.com/users/17846/mark-c

The contents of this email are intended only for the individual(s) to whom it is addressed and may contain confidential or privileged information. If you are not the intended recipient, you must not disclose, copy, distribute, or use the contents of this email. If you have received this email in error, please notify the sender immediately and

delete the email and any attachments.

On Wed, Dec 10, 2014 at 11:53 PM, bgirardot notifications@github.com wrote:

I agree with pierzen, but I also love the idea of what althio mocked up above.

For a lot of projects, just selecting from that list and having it pull in pre-written, clearly formatted instructions, in multiple languages, would cover the task well.

But I am fairly sure that no one is talking about removing any of the "free form" fields project creators can use now, but that a selection list like althio shows would be in addition to the free form fields. Selecting from the list would just basically "pre populate" the free form fields we have now.

I would love to see the actual instructions for those items in the osm wiki, with multiple languages for each set of instructions. Clicking on any of the check boxes would just go to the wiki, grab each language version of the instructions for that item and insert them into the project creation form for each language that was available.

This would let us refine the instructions and make it easy for anyone to review the instructions outside of the tasking manager and add a translation of the instructions for that item. And it would keep the text of the instructions for each language out of the tm2 code base where they would be much harder to maintain, adjust and translate.

If you check a box for an item that doesn't have instructions in the wiki yet, you would just get a notice that the wiki did not contain any text for that item, please write the instructions yourself and when done please add them to the wiki for next time.

And of course, if a project creator doesn't want to use the preset instructions, they can check the box, get the default from the wiki and then edit it on the project edit screens as they wish, or not check the box at all and just write or copy/paste their own instructions.

— Reply to this email directly or view it on GitHub https://github.com/hotosm/osm-tasking-manager2/issues/172#issuecomment-66472729 .

althio commented 9 years ago

I am not familiar (yet?) with the steps required to create a project. So of course your feedback @pierzen is really important here. I may repeat some of the points that @bgirardot made in-between.

I see the project creation as a 2-step process. If the 'project template' is included it would be only the first step.

  1. You fill in the form. At the end of the form you would end up with a template. The idea is to have 95+% of the work done at this stage with the minimal amount of work and time. It means the form and the template are well designed. I guess most project creation have this first step covered by duplicate or copy-paste from earlier projects.
  2. As a second step that template could be modified at will by the owner to create the actual new project.

So my list is only a draft, a minimal list of all the items that are common and foreseeable. I know I missed some. I can now think of evacuation centers, destroyed or damaged buildings... But the big task is to agree and create the form. An additional field to be added later on does not seem a big hurdle. Anyway as stated by @bgirardot and maybe others: the form should not exclude possibilities of free text. Maybe a feature to add new sections on-the-fly is needed? But if recurrent it should be added back to the default form.

Only the items ticked at creation would be used after the project is launched.

I can feel that my above statement is quite imprecise and certainly misleading. It would be best indeed if we could edit the project after creation, come back to the form and modify it at will. But that should be weighted: maybe it is better to leave a project as defined and create a new one with different objectives (new area, new tags, more detailed mapping...). I think it is common (and good) practice to split up the work with a first project for main roads and then separate projects to refine as needed. @MarkCupitt Furthermore if you can duplicate a project, you could have all the attributes from the form duplicated as well.

Advantages from a well-designed form+template (from the advocates @AndrewBuck @bgirardot @CloCkWeRX and myself):

althio commented 9 years ago

Related issues for project creation, project attributes/tags and instructions standardisation:

  1. step: 'form' to fill in. #172
  2. step: 'template' including formatting and structure for instructions. #132