Arvados

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

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.

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.

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"?

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.)