I'm writing up instructions under http://drupal.org/node/1053378 about using sandboxes as the recommended workflow for major initiatives.

When you create a sandbox, the first thing you're presented with is this choice:

Project type selection

If you're working on a core initiative, it's going to be a natural choice to select "Drupal project" there. However, that term is reserved for only "official" projects like Drupal core, Drupal.org webmasters, etc. and this will quickly become a gigantic mess if everyone's sticking their stuff there.

I think the "real" solution to this is to prevent selection of one of these taxonomy selections on sandbox projects altogether and force it to be "Sandbox" or something behind the scenes. Or some kind of JS disabling thing or whatever.

However, given our launch timeframe, I'm thinking of just adding a "Sandbox" term and recommending in the documentation that people pick it.

Sound ok?

Comments

sdboyer’s picture

sdboyer commented

There's definitely some overlap between the taxonomy for projects and the 'sandbox'. However, I'm pretty against this. The 'sandbox' axis is really distinct from the project type axis, and conflating them just makes it more confusing. People should know if they're creating a module or a theme when they initially start a project, and it's important we know that for other purposes too.

Let's not trade one problem for another.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Ok, that's fair enough.

So then how do I properly categorize "I'm creating a temporary fork of core so that I can make Drupal output HTML5 by default"? It's not a module, it's not a theme. The closest thing in the list is "Drupal project", but that's reserved for "official" projects related to the Drupal project, not my random core initiative.

But same applies to, "I'm creating a temporary fork of Version Control API so that I can make it support Visual Source Safe." While it's a "module", in the technical sense, I really don't want it to show up under drupal.org/download as a "new" module; it's merely something I'm tinkering with.

So it seems like an extra facet of taxonomy is missing here for this use case.

mikey_p’s picture

mikey_p commented

We have other ways that we are making sure that sandboxes don't show up. This is also going to really (#*%& with the project selector drop-down at node/add/project-issue since we are already hiding sandbox issues there (see #1026502: Hide sandbox projects at node/add/project-issue).

I think that what we really need is just a 'other' category anyway. What about projects like drush, or a plugin for my favorite IDE, or a set of bash scripts for managing Drupal checkouts with git? All of those are valid projects that don't fit in the categories we have now.

I'd much rather see work go into making the vocab optional, or add an 'other' option rather the make sandboxes even more confusing.

mikey_p’s picture

mikey_p commented

Also I'd add that this is just a stop-gap measure anyway, until we get per-issue repos working. At that time we won't people doing forks to separate projects, so what will we do with all the projects in the sandbox category?

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Ok, we spoke about this on the phone and came to an agreement. :) The way we're going to handle this is have people add their collaboration sandbox projects as "Modules", with the category of "Community initiative". I added that term, and now just need to update the docs.

dww’s picture

dww
we/he/they
commented

I don't understand what's wrong with sandbox forks of core being in "Drupal Project"?

Oh, probably because the "Drupal.org Projects" tab in the "drupal.org" site section is just pointing to http://drupal.org/taxonomy/term/13 -- but that's sort of dumb already. We should probably be using a solr query there just like other project browsing pages...

That's how I'd solve this...

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Because it infers some sort of official legitimacy these projects don't have. Also, if I fork Views to work on some huge thing for awhile, that's not a "Drupal project" project, and it's also not a "Module" I want found with other modules.

dww’s picture

dww
we/he/they
commented

@webchick: "want found with other modules"? Where's that happening? #1031578: [Meta] Reflect a consistent strategy for sandbox visibility means you'll never see sandboxes unless you're explicitly looking for them. A fork of the views module is a views "Module". It's sure as hell not a "Theme"...

Honestly, there's no validation or ACLs for who can use "Drupal Project" already, so cruft getting in there is independent of the Git migration.

I'm hugely -1 to a task with the current title Add "Sandbox" as a term under the "Projects" taxonomy. Evil. Ditto a "module" category called "Community initiatives". These are both wildly confusing mis-uses of classification. Let the project taxonomy represent what it's supposed to (core vs. module vs. profile vs. theme, etc) and let the sandbox bit work on an entirely separate dimension, and don't confuse the two. If you fork core, it's still core, not a module. If you fork a theme, it's still a theme. Etc.

I'd strongly favor "won't fix" this issue with a spin-off issue in drupalorg_crosssite to fix "Drupal.org Projects" to point to a project_solr browsing query, not http://drupal.org/taxonomy/term/13. We should do that anyway (completely irrespective of the Git migration).

eliza411’s picture

eliza411 commented

Not trying to weigh in on the actual solution or the priority, just restating the problem as I understand it:
As we lower the barriers to entry by providing sandboxes and as we enable the community to work together in new ways, this is a stumbling point. The user is forced by a required field to choose something that doesn't make sense to them.

Additionally, sandbox collaborations don't have a way to be identified via filters, and they are a conceptual category that has value for certain segments of our users.

dww’s picture

dww
we/he/they
commented

Re: lowering barriers -- in phase 3 we could add a "clone this project" button which takes you to a node/add/project-project page with the sandbox bit set and all the other stuff filled in appropriately with a few required fields for you to explain what you're cloning for (or something)...

Until then, I'd rather we not completely confuse the project taxonomy stuff for this case. If people have trouble getting it right, let's improve the UI and/or add more help text/docs. But adding bizarre choices doesn't seem like it's going to help anyone be less confused...

Cheers,
-Derek

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Hm. Yeah, i guess we could do that. That doesn't sound like something we can accomplish before launch, though...

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Title: Add "Sandbox" as a term under the "Projects" taxonomy » Figure out what to document for "Project type" for people doing sandbox collaboration

Also, re-titling.

This is what this issue is actually about.

dww’s picture

dww
we/he/they
commented

#1070310: Split "Drupal project" taxonomy term into "Drupal core" and "Drupal.org projects"
#1070312: Prevent promoting projects of the "Drupal project" (and "Drupal core") project type(s)
#1070314: Remove taxonomy listing for "Drupal.org projects" and restore the Solr search for it

eliza411’s picture

eliza411 commented
Project: Git on Drupal.org » The Great Git Migration
Component: User interface » Decisions
Issue tags: +git phase 2 leftovers

Tagging and moving this out of the testing queue in preparation for migration day.

dww’s picture

dww
we/he/they
commented
Status: Active » Reviewed & tested by the community

Everything in #13 is now done. If you fork core and make a sandbox, you should mark it "Drupal core". If you want to find other core sandboxes, they're here:

http://drupal.org/project/drupal%20core?filters=bs_project_sandbox:1

Not sure exactly what docs need updating to reflect this, but it seems we have an answer. So, setting to RTBC.

Cheers,
-Derek