Refine archived status: 'completed' versus 'archived'

[ethan-nelson]

A few issues have brought up concerns about archived task access, with valid use cases and reasons on both sides whether or not to allow access. I propose we instead evolve the 'archived' status into two categories instead:

• Completed, which signals that the project was a success but contributions are no longer requested...think read-only for any user, and adding any comments, tile taking, tile marking, tile validating/invalidating are all restricted to only project managers and admins.
• Archived, for projects that really don't want to be displayed anymore. These could be duplicates, ones with bad instructions, etc. Viewing these will be limited to project managers and admins.

This will be mostly trivial to implement with one major transitional barrier: someone/some people will have to go through all of the previously archived projects and either mark (a) bad ones archived or (b) good ones completed...depending on how we transition the database. By doing this, we can ensure statistics about older successful projects are retained and publicly accessible for groups like OSM-Analytics.

[pgiraud]

Thanks for your analysis. Thinking a bit about it a bit more, I'm not sure we did the right thing by preventing users to access to archived projects. Hiding archived projects from the list on the homepage is obviously a good idea so that we get mappers to work on the active projects. But restricting access to it is probably not necessary.

Till now projects can be archived in two cases:

• the mapping work is finished. This correspond to what you call completed. However, this doesn't necesseraly mean that the work is completed. For example, projects can be archived automatically at a given date.
• the project is invalid. Duplicate, contains error, etc. They could be deleted.

This means that I agree with you. I'm not sure about the names though. Completed & Archived names don't exactly mean what they should.

Finally, I think it would be OK to expose all the projects through the API at first and ask the project managers to mark the projects as invalid (or any other name) for projects. FYI, it looks like about 20% of the projects are archived. It was at least the case last year. This would mean about 370 projects nowadays.

[russdeffner]

Would agree with you @pgiraud - we are currently doing further validation on projects after archiving as a way to restrict to only Project Managers, I know we can do this with Private project as well, but I think that is also the better way to restrict access to any project archived or not.

[ethan-nelson]

Alright, I'll see if I can flesh this out over the weekend.

For the first, perhaps closed may be a better suited name to indicate its status as closed to contributors (except PMs or admins).

I also agree archived probably isn't the best adjective for the other state but am unsure about an alternative for it. Ideally, to me at least, projects that would fall under this category are only ones that are unwanted, so this is this more of a quasi-delete status than just a "don't map here anymore".

[althio]

I ses this as two statuses:

• active / closed [project is live for editing] vs. [project is read-only]
• published / unpublished [project is visible] vs. [project is hidden]

For the first, perhaps closed may be a better suited name to indicate its status as closed to contributors (except PMs or admins).

This one would be published and closed.

I also agree archived probably isn't the best adjective for the other state but am unsure about an alternative for it. Ideally, to me at least, projects that would fall under this category are only ones that are unwanted, so this is this more of a quasi-delete status than just a "don't map here anymore".

This one would be unpublished (and closed).

[ethan-nelson]

So @althio, if I understand you correctly, we could translate the four states into the following:

Status	Published?	Open?
draft	unpublished	open
published	published	open
closed	published	closed
archived	unpublished	closed

The question is then if we want to expose this publish/open schema to project admins or leave it at the previous statuses. I'm not sure which would be more confusing versus easier for people to understand. That includes factoring in having users set two separate fields versus one for some transitions e.g. from published -> archived.

[althio]

Yes that is what I see.

I would also say that unpublished does not care about open and close. So unpublished=draft=archived, but I may be missing some use case?

So I would have only 3 statuses:

• unpublished (draft)
• published (live)
• closed (read-only) and back to unpublished if needed.

The thing is more vocabulary in my mind than code. And to avoid archived, I found it too confusing.

[aawiseman]

Closed might also be called "Done" or something. This was mentioned at the Missing Maps meeting in Brussels

[bgirardot]

@aawiseman This is not closed as far as I know. More feedback is needed as I think some database changes are coming, fleshing out ideas like this are needed.

[bgirardot]

I think I commented on this before.

Could it be we are looking at this the wrong way?

Rather than statuses, are we really talking about attributes of the project?

I have no idea if this is a good idea, but something like rather than a status, we just allow certain things on a project like:

• [ ] Can be mapped
• [ ] Can be validated
• [ ] Show in search results
• [ ] etc

Setting a status would just check a predetermined group of checkboxes. Project managers could then add or remove checks from the options on the project.

Just a slightly different way of thinking about it, rather than trying to force groups of these allowable things into "status"es and coming up with names for the different statuses.

[ethan-nelson]

Yeah I was rethinking this whole idea once you suggesteded the concept of both project- and instance-level permissions for editing and validating. I think it can boil down to a granular permissions-system based on action and person:

Role	View	Edit map	Validate
PM and admin	[ ]	[ ]	[ ]
Global users	[ ]	[ ]	[ ]
Project users	[ ]	[ ]	[ ]
Other users	[ ]	[ ]	[ ]

In this case, 'project users' would be people defined by the project manager (which we haven't implemented yet exactly how they are added from #899) and 'global users' would be those that have received the check mark or status from whoever. 'Other users' would be someone who doesn't have global verification nor specified by the project manager.

[ethan-nelson]

Expanding a little further, projects could start out with:

Role	View	Edit map	Validate
PM and admin	[ X ]	[ X ]	[ X ]
Global users	[ ]	[ ]	[ ]
Project users	[ ]	[ ]	[ ]
Other users	[ ]	[ ]	[ ]

Once the project is out of a draft stage, it could look something like this:

Role	View	Edit map	Validate
PM and admin	[ X ]	[ X ]	[ X ]
Global users	[ X ]	[ X ]	[ X ]
Project users	[ X ]	[ X ]	[ X ]
Other users	[ X ]	[ X ]	[ ]

Private projects would follow:

Role	View	Edit map	Validate
PM and admin	[ X ]	[ X ]	[ X ]
Global users	[ ]	[ ]	[ ]
Project users	[ X ]	[ X ]	[ X ]
Other users	[ ]	[ ]	[ ]

More difficult projects might use something like:

Role	View	Edit map	Validate
PM and admin	[ X ]	[ X ]	[ X ]
Global users	[ X ]	[ X ]	[ X ]
Project users	[ X ]	[ X ]	[ X ]
Other users	[ X ]	[ ]	[ ]

Either way, once completed, it could move to:

Role	View	Edit map	Validate
PM and admin	[ X ]	[ X ]	[ X ]
Global users	[ X ]	[ ]	[ ]
Project users	[ X ]	[ ]	[ ]
Other users	[ X ]	[ ]	[ ]

[rachblevine]

I just wanted to second (or third or fourth as the case may be!) the idea to not archiving / hiding past projects. We have accomplished so much, and the tasking manager could be a great tool for showcasing our work, both past and present. When non-admins aren't able to see the full scope of our work it limits our abilities to collaborate across organizations. It also minimizes the impact our narrative can have on the public / independent volunteer population. Basically, one can only build off other's building blocks if they are aware of them! It sounds like Russ and others often return to "finished" projects for continued validation or editing. Maybe we need a two part system? Most projects we'd keep live but add "Finished/Done/Complete&Validated" to the title. This could be would allow the public to be aware of our work, but know not to keep mapping the specific task while still allowing us to continue to on as needed. The second option would be used less and would be an archive/delete option. If a task is a duplicate, sensitive or what have you, I think this option is important to have but a tool we should use less often. Anyways those are just my 2 cents. Thanks!