-
Notifications
You must be signed in to change notification settings - Fork 156
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
Comments
Thanks for your analysis. Till now projects can be
This means that I agree with you. I'm not sure about the names though. 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 |
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. |
Alright, I'll see if I can flesh this out over the weekend. For the first, perhaps I also agree |
I ses this as two statuses:
This one would be
This one would be |
So @althio, if I understand you correctly, we could translate the four states into the following:
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. |
Yes that is what I see. I would also say that So I would have only 3 statuses:
The thing is more vocabulary in my mind than code. And to avoid |
Closed might also be called "Done" or something. This was mentioned at the Missing Maps meeting in Brussels |
@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. |
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:
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. |
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:
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. |
Expanding a little further, projects could start out with:
Once the project is out of a draft stage, it could look something like this:
Private projects would follow:
More difficult projects might use something like:
Either way, once completed, it could move to:
|
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! |
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 onescompleted
...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.The text was updated successfully, but these errors were encountered: