Meta: Visually distinguish sandbox projects from regular projects when viewing them [#984734]

Over in #961144: Determine/finalize technical requirements for post-Git migration project approval process, we came to consensus about a few different things:

1. There will no longer be an application process stopping people from committing code to drupal.org. Instead, anyone who agrees in their d.o profile to post GPL code will be able to create projects and commit stuff.

2. Because these projects might contain experimental code, might never amount to anything, etc. we don't want to pollute the very limited project URL namespace with them (http://drupal.org/project/views et al). So initially, they won't be given a shortname, but will instead be referred to by http://drupal.org/node/129893).

3. "Real" projects get release nodes, and they get human-readable short names, and they show up in search results/listing pages, where "experimental" projects don't.

There needs to be some clear way of visually telling right away an "experimental" project to a "real" project, which is the point of this issue to discuss.

- First we need some way of programmatically telling these two things apart. According to dww/mikey_p, the Project module isn't like OG where it can be applied to multiple node types. So we'd have to use something like Taxonomy for indicating "Experimental" project vs. "Real" project. So one easy way to determine between the two is that one would have a taxonomy term "Experimental."

- We could then style the project nodes differently on drupal.org based on the presence/absence of this term. For example, a banner like "Fork me on GitHub" like on http://html5demos.com/. Appending "[experimental]" to their node titles. A blinking red background. Whatever.

So... let's talk. :)

Comments

Comment #1

webchick

she/they

English

Vancouver 🇨🇦

commented 30 November 2010 at 00:09

Priority:	Normal	» Major
Issue tags:		+git phase 2

We definitely should do this, but I don't think it blocks release, so marking "Major" rather than "critical."

Comment #2

dww

we/he/they

commented 7 December 2010 at 15:32

Title:	Determine way to indicate that sandbox projects are untrusted, non-canonical or experimental code	» Visually distinguish sandbox projects from regular projects when viewing them
Project:	The Great Git Migration	» Project
Version:		» 6.x-1.x-dev
Component:	Decisions	» Projects
Status:	Active	» Postponed
Issue tags:		+git sprint 6

Once #986718: Add support for sandbox projects lands, this is a project.module UI problem, not a Git migration decision.

Comment #3

dww

we/he/they

commented 10 December 2010 at 12:31

Issue tags:

+sandbox projects

Adding 'sandbox projects' tag to make this effort easier to track across issues and queues...

Also, before we can implement this, we need to design the UI. ;) If anyone has suggestions, mockups, etc, that'd be really helpful.

Thanks,
-Derek

Comment #4

dww

we/he/they

commented 17 December 2010 at 18:42

Status:

Postponed

» Active

#986718: Add support for sandbox projects landed. This can now happen.

Comment #5

eliza411 commented 17 December 2010 at 22:32

Issue tags:

+git sprint 7

Tagging for Git Sprint 7.

Comment #6

mikey_p commented 23 December 2010 at 00:15

I was thinking about this randomly today and through about maybe prefixing the title on display with something like the author's name, similar to github. That part of the title could even be a link to a list of project's by that user. Something like:

mikeyp's sandbox: DevNull Storage Engine

Only perhaps with the actual project title in a smaller type size.

Thoughts?

Comment #7

dww

we/he/they

commented 29 December 2010 at 18:53

Whatever we do here, it'll be nice to link to this when it's done:
#1009996: Add a handbook page explaining WTF a "sandbox project" is

Comment #8

webchick

she/they

English

Vancouver 🇨🇦

commented 30 December 2010 at 06:48

Assigned:

Unassigned

» webchick

Ok, I have been anointed The Decider™ on this by Sam and Kieran.

And Neil has asked that whatever we do here doesn't break the existing site styling, so that means re-using existing classes/page elements.

I'm going to see if I can find a designer-type online tomorrow and get some input on this before just barfing out the first thing that comes to me. ;P

Comment #9

webchick

she/they

English

Vancouver 🇨🇦

commented 31 December 2010 at 03:01

Assigned:

webchick

» Unassigned

Ok, here is a mockup that Bojhan and I cooked up, and has been given approval by mikey_p, sdboyer, and eliza411. Let's call this "the spec":

Three changes to existing project pages

Here you see three changes to existing project pages, numbered:

1. We add a link <a href="/project/[uid]?sandbox=true">[username]'s sandbox</a> preceding the project title. This will link back to the existing user-specific project view, which will need the following changes.
a) An exposed filter to limit the list to "sandbox" projects, which the link will toggle to on.
b) The addition of a "sandbox" column to the table which indicates if it's a sandbox project or not.

2. A yellow box to draw attention to the project which is the same styling as we use on book pages where they contain insecure code.

Here's the HTML and text:

<div class="meta">
  <h5>Experimental Project</h5>
  <p>This is a <a href="/node/1011196">sandbox project</a>, which contains experimental code for developer use only.</p>
</div>

3. There are a few different changes here:
a) We remove the "Project details" block, which has no place on a sandbox project.
b) We also remove the links to view/download/create releases
c) We replace the typical download table with the following:

<form>
<input style="font-family: courier; width: 500px;" value="git clone git://git.drupal.org/sandboxes/mikey_p/12345.git" />
</form>

(Note these inline styles should be made all nice and CSS-ified, but I don't have access to BlueCheese. Also, please do whatever is needed to make that code XHTML validate.)

Comment #10

aspilicious commented 31 December 2010 at 13:37

P*E*R*F*E*C*T

Comment #11

eliza411 commented 31 December 2010 at 21:02

Issue tags:

+git sprint 8

Tagging for Git Sprint 8

Comment #12

dww

we/he/they

commented 1 January 2011 at 19:32

Title:	Visually distinguish sandbox projects from regular projects when viewing them	» Meta: Visually distinguish sandbox projects from regular projects when viewing them
Issue tags:	-git sprint 8

Love it. The only thing to consider is which of these belong in project*, which belong in drupalorg_project, and which belong in versioncontrol_project. ;)

Note that all the release related links and such are already hidden on projects that have releases disabled. For example:

http://drupal.org/project/infrastructure

Thanks to #994260: Add a setting to disable releases for sandbox projects that's what all sandboxes will be. So 3b is already "done".

The "Project details" block from 3a already lives in drupalorg_project, so logic to hide it on sandboxes belongs there.

3c could be in vc_project, although given it's git-centric (and really, git.d.o-centric) that might as well just happen in drupalorg_project, too.

1 and 2 both seem reasonable for project* itself to handle. 1a and 1b are really changes to project_issue, since project_issue is responsible for the "My projects" view and page. Note that the table you're talking about at the top of that page isn't a view at all, but care of project_issue_my_projects_table().

Given all of that, I think this issue is going to be too confusing moving around from queue to queue. Hence, I'm turning this into a meta issue to coordinate all the other subtasks. My net is so flakey here, I don't think I'll be able to create all the individual sub-task issues and link them here, but I think that'd be very wise. I think we need at least 3 issues: one for drupalorg_project for 3a + 3c, one for project_issue for the "my projects" changes from 1, and a final issue here in project itself for 2 and the title changes from 1. Maybe. ;) Or maybe this issue can handle the project.module changes itself.

Anyway, great work on the spec, and I hope this implementation roadmap helps!

Cheers,
-Derek