Story #6405

[Workbench] Allow additional curation of the public projects listing

Added by Brett Smith about 4 years ago. Updated about 4 years ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
Workbench
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
-

Description

Sasha says an opt-in approach is generally preferable to opt-out.

Possible approaches:

  • Link objects that specify what projects should be listed.
  • Tag groups, then the listing only lists projects with a specific tag.

Tom needs to spec out a specific implementation.

curated_public_project.png (152 KB) curated_public_project.png Radhika Chippada, 06/30/2015 03:15 PM

Related issues

Related to Arvados - Story #6307: [Workbench] Public project listing should exclude subprojectsNew

History

#1 Updated by Brett Smith about 4 years ago

  • Description updated (diff)

#2 Updated by Nancy Ouyang about 4 years ago

A related issue is how to make sure there is a clean presentation of public projects and datasets (mostly for new users), that way we do not have a mess of not-well-groomed projects. The original idea presented below was to have a manually-curated list of public projects, perhaps with a "★" rating system, but automatically or opt-in are attractive alternatives.

https://arvados.org/issues/5495 :

We should also publish some guidelines for inclusion in curated selection:
1. documented
2. has readme
2. describes how to check that output of pipeline is correct

#3 Updated by Brett Smith about 4 years ago

  • Category set to Workbench
  • Target version changed from 2015-07-22 sprint to 2015-07-08 sprint

#4 Updated by Tom Clegg about 4 years ago

It sounds to me like we have a "public projects" page but what we really want is a "featured projects" page.

That could be achieved by creating a project called "Featured Projects", sharing it with Anonymous, moving the featured projects into it, and making some changes to Workbench:
  • Create a new config knob "featured_project_uuid"
  • Replace the "public projects" with a link to the configured featured_project_uuid. The link title can be the name of the project itself, or it could be a second config knob "featured_project_uuid_link_text".
  • Rename the ProjectsController "public" action to "index". (Move the dashboard view and root route (which currently abuse the ProjectsController#index action) to UsersController#dashboard.)
  • Route /projects/featured (and, to avoid breaking bookmarks, /projects/public) to the featured projects page if one is configured.
    • resources :projects do
        if Rails.configuration.featured_project_uuid
          get :featured, on: :collection, defaults: {owner_uuid: Rails.configuration.featured_project_uuid}
          get :public, on: :collection, defaults: {owner_uuid: Rails.configuration.featured_project_uuid}
        end
      end
      
  • In the new #index action:
    • if param[:owner_uuid] is given, look up projects with the given owner_uuid. Display with the existing "public" view (which will presumably be renamed to index.html.erb).
    • otherwise, redirect to home project (or root_url if not logged in). (AFAIK, we don't link to this from anywhere...)

If we also want to publish an uncurated list of all public projects, /projects/ would be a natural place to do that (instead of redirecting to home/root). But it sounds like we don't.

#5 Updated by Radhika Chippada about 4 years ago

  • File curated_public_project.png added

A few concerns about this approach.

  • "moving the featured projects into anonymously shared featured projects project" : If we go this path, are we not compromising on our vision of "publicly accessible projects" feature? A non-admin user "x" will not be able to add his/her public project to this page / project; only admins or owner of the featured_project_uuid can move projects into it
  • Can we not accomplish the "tag projects" to list in public projects page by simply enhancing minimally the current "sharing" implementation? How about we add an extra checkbox to "list this project in public projects page" for each project sharing row that is shared with anonymous users? Please see the attachment [[https://arvados.org/attachments/download/648/curated_public_project.png]]. I think we can add this as property on the sharing link and a user can mark check this checkbox after sharing a project with anonymous users.

#6 Updated by Radhika Chippada about 4 years ago

  • File deleted (curated_public_project.png)

#7 Updated by Radhika Chippada about 4 years ago

#8 Updated by Brett Smith about 4 years ago

Radhika Chippada wrote:

"moving the featured projects into anonymously shared featured projects project" : If we go this path, are we not compromising on our vision of "publicly accessible projects" feature? A non-admin user "x" will not be able to add his/her public project to this page / project; only admins or owner of the featured_project_uuid can move projects into it

We would be compromising on that vision, yes—intentionally. A combination of user feedback and additional thinking through different use scenarios has us thinking right now that having the admin serve as a gatekeeper for what's on the page would be useful.

For any installation that wants to let all users add stuff to the featured projects page, that would be easy to accomplish by giving the All Users group can_write permission to the Featured Projects project.

#9 Updated by Tom Clegg about 4 years ago

There are a couple of points to address. One is which features are desired (and how urgently). Here's my understanding:

Category Description Implemented now Desired?
World-readable projects All projects that are designated world-readable by the users. Yes, via "Public Projects" and the Projects drop-down Yes, but not urgently
Published projects Subset of world-readable projects elevated to "published" status by users. No ?
Featured projects Subset of world-readable projects elevated to "featured" status by a site admin. No Yes, soon/now

I don't quite follow which use cases motivate the distinction between "world-readable" from "user-published". The difference between them seems to be "projects which should show up in Search, and in the Projects drop-down under the Shared heading, but not on the "Published projects" listing."

Another is the issue of ownership. Moving a project into "featured projects" makes it look like it's "ultimately owned" by the curator rather than the original contributor. I think this might be just a UI issue: ownership should be presented as "anyone who has manage permission", rather than following the parent/owner trail to a single entity.

Another is UI: Should the "world-readable" (and/or "published") flags be presented as a separate toggle switch, rather than "share with the Anonymous Users group"?

#10 Updated by Tom Clegg about 4 years ago

Brett Smith wrote:

For any installation that wants to let all users add stuff to the featured projects page, that would be easy to accomplish by giving the All Users group can_write permission to the Featured Projects project.

This would also have the side effect of giving all users write permission on one another's featured projects. I think it will be worthwhile to have a "featured" mechanism that doesn't have this side effect. (Either way, it's out of scope here.)

#11 Updated by Brett Smith about 4 years ago

  • Target version changed from 2015-07-08 sprint to Arvados Future Sprints

This will be done in a future sprint when we can have some more planning around use cases and functional requirements.

Also available in: Atom PDF