Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refine archived status: 'completed' versus 'archived' #788

Open
ethan-nelson opened this issue Apr 28, 2016 · 12 comments
Open

Refine archived status: 'completed' versus 'archived' #788

ethan-nelson opened this issue Apr 28, 2016 · 12 comments

Comments

@ethan-nelson
Copy link
Collaborator

ethan-nelson commented Apr 28, 2016

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
Copy link
Collaborator

pgiraud commented Apr 28, 2016

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
Copy link

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
Copy link
Collaborator Author

ethan-nelson commented Apr 28, 2016

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
Copy link

althio commented Apr 29, 2016

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
Copy link
Collaborator Author

ethan-nelson commented Apr 29, 2016

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
Copy link

althio commented Apr 29, 2016

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
Copy link

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

@bgirardot
Copy link
Contributor

@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
Copy link
Contributor

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
Copy link
Collaborator Author

ethan-nelson commented Dec 14, 2016

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
Copy link
Collaborator Author

ethan-nelson commented Dec 15, 2016

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
Copy link

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants