Phase out sandbox projects

Existing projects could just be promoted to full projects, with a redirect to handle the old URLs.

-1 from me.

I think sandboxes are still useful and would prefer this project type to stay. I use them for two purposes:

1. Custom Drupal projects I create for, and want to share with, a very limited audience (e.g. students or clients) are sandboxes. I don't want them to appear as full projects because that would imply that they're useful to others – and well, they're not. I don't want to confuse people.
2. To have a bogus issue queue where I can upload images to Drupal.org to embedded in my forum posts. (This is basically a workaround of the limitation that there is no upload image button for forum posts, so using a sandbox for this will no longer be necessary when that is fixed.)

It will not be the end of the world if sandboxes go away, but they still have some uses.

Gisle:
So in the first case you want to upload a project and make it open source but don't want other people to use it, and in the second case you're working around a bug in another part of d.o? You might consider that the first scenario that "beauty is in the eye of the beholder", i.e. if someone else finds it useful then so be it, it's a little silly to open source something but say nobody should use it. In the second scenario, you might open an issue on the drupalorg project that allows people to add images to forum posts, so you don't need a workaround.

1. I don't want other people not to use it. It is free software, so of course they can use it if they want to. But it is very unlikely it will be useful for people outside the educational setting it has been created for (i.e. it won't even be useful as education without additional teaching materials and in-person lectures by me). I simply don't want to waste anybody's time by making such projects visible as full projects. I do my best to provide support for my full projects here. I don't support sandboxes, (and I hope nobody expects sandboxes to be supported).
2. Three issues has been created requesting this - see #2926532: Provide file upload for forums (the other two are closed as duplicates). You know as well as me that opening an issue does not always result in it being fixed any time soon.

1. Could this be handled by just indicating the project is open to new maintainers?

Could this be handled by just indicating the project is open to new maintainers?

Well, we have a clear policy on sandboxes, spelled in the grey box on top of this page: https://www.drupal.org/node/251466

TL;DR: If you want to maintain and use a sandbox, just go ahead and clone it! You can even make it a full project of you want to.

A sandbox is always open for someone to clone and maintain if they want to make use of it. There is no red tape involved in becoming a maintainer of its code. That's another sweet thing with sandboxes that I am going to miss if they're phased out.

However, if sandboxes are no longer allowed, I certainly don't want anyone to change the code I use for training purposes. So there is no way I am not going to promote it to a full project and then open the project to new maintainers.

If sandboxes go away, I shall delete the project's Drupal.org repo (I assume that this will be an option before they are phases out). I'll then switch to distributing it as a tarball from my own server, old school style. But composer has grown on me, so using a Drupal.org sandbox project on Drupal.org for my first use case has a lot going for it.

There's always github or bitbucket for sandbox projects, leaving d.o for projects people want to be open to collaboration.

The other thing to keep in mind is that I can delete my own sandbox projects, so sometimes I find it useful to create something as a sandbox first when it's really a proof of concept, and promote it to a full project when it's actually ready for other sites to use.

I know you've said that devs could use other sites like GitHub or Bitbucket to post those kinds or projects instead, but do we really want to push people away from sharing code on drupal.org? It's worth pointing out that having the code offsite means it won't show up in module searches on Drupal.org.

The thing with transforming sandbox projects into full projects is that D8 projects will be made available on the drupal package registry (composer), isn't it? If so, that seems not desirable for most of them.

Maybe add a state selector on the project's page to tell if the module is added or not to the registry. Create a sandbox package repository. In regards with this new selector, the module will be added to either package registry.

So, instead of adding a package type repository in the composer.json, we could add the more general drupal-sandbox repository, then do something like: composer require drupal-sandbox/a-sandboxed-module.

That's a very going point, thank you @Dakwamine.

Making sandboxes full projects without additional changes also brings up problems with project overlapping. Right now I can create a sandbox with the name "webform", effectively forking Webform. What would happen if sandboxes turned into full projects, would my Webform fork be downloaded by someone trying to download Webform?

It's not possible to create a sandbox project with the same name another project is already using, and it's not possible to set the machine name for a sandbox project. It's also not possible to create a full project with the name already used by a sandbox project.
That type of conflict is not possible.

When you create a sandbox it doesn't ask you for the short name, that only comes up when you promote it to a full project, or try to create a full project in the first place.

If the community does away with sandbox projects this scenario will need to be handled.

Promoting a sandbox project to a full project which conflicts with an existing full project isn't possible.
What described in comment #11 cannot happen: The short project name asked when promoting a sandbox project cannot be one already used, and the project name entered when the sandbox project is created cannot be one already in use too.

I suspect the most we can do for existing sandbox projects is disconnect them from the project and keep the repositories read-only.

Maintainers can delete their own sandbox project. There should not be an expectation from end-users that sandboxes are permanent. It would be technically okay for us to delete them, on a generous, well-announced schedule. However, that would not be a great thing to do.

We could see how far we get with asking maintainers to delete or promote their own projects. I suspect that would not get a large portion of them moved.

I don’t think mass-promoting all sandbox projects would go well. We can work around the naming issue by appending a number to get around conflicts; it is a good convention to have the project name match what’s inside it, but that’s not required. There would be other issues like that. We could promote them with a low maintenance/development status to match maintainer expectations. Promoting them all still feels like it would not be good for the maintainers or end-users.

As usual, I'm late to the game but can I ask what the reason is behind deprecating sandbox projects other than we want to do it? I agree with @gisle. It doesn't make sense to always require a full project when you just want a sandbox to play around in that has no restrictions and that may go away if it turns out to be a bad idea or your use case is no longer needed.

@uberhacker The plan is using less custom code on Drupal side and depending more on what GitLab offers. (Drupal.org will upgrade to Drupal 9.)

I agree with @gisle and would suggest to have some alternative for sandboxes , like alternative namespace instead of makinf them integrated into full projects namespace on Gitlab.

I believe they are helpful when you want to play with something or teach some juniors on how to make contributions to drupal.org or making new comers familiarise with Drupal issue queues.

For example I created a sandbox project for a particular core issue . It doesn't make sense to have a full project just to share a temporary test module to reproduce that issue. If I make it as a full project I would be taking away the available module namespace, which will cause issue when some other developer wishes to release a proper module with the same namespace.

And other case where I use sandbox projects is, if I want my juniors to get familiarise with Drupal contributions I would ask them to create a sandbox project first and make the changes there first before cluttering the issue queues.

Since Sandboxes are not recommended, what is the recommended way of experimenting with Drupal's Gitlab integration, to get familiar with using it? For new users, having to experiment and possibly fail on live issues is less than ideal ...

It would be nice to clarify this after this sentence, on the Creating a new project > Sandbox projects documentation page:

The switch to using GitLab, and the fact that anyone can now create a "full" project without requiring the extra step of obtaining the git vetted user role makes the use of sandboxes obsolete.

Maybe add something like this? (Assuming that this is correct, if not let's find a proper wording for a recommendation)

If you need to experiment with Drupal's Gitlab integration, for example doing Gitlab Merge Requests, you can create a new test project via https://www.drupal.org/project/add, using the "Full project" type. You can delete it, when you are finished with your experiments.

It would be great to include a clarification on this in the Issue Summary here, and add it to the Sandbox documentation page, possibly creating a new page. Or maybe such a page already exists?

I propose we reconsider deprecating sandbox projects in light of the use of AI to abuse the system.

• Non-vetted contributors should only be allowed to create sandbox projects.
• A sandbox project should only be promoted to a full project by a vetted contributor.
• A contributor who creates a release without reviewing it should be given a warning.
• A contributor who creates a release without reviewing it after being warned should lose vetted status for a year.

See #3521303: LLM-generated modules have been published for an example of a contributor using AI to abuse the system multiple times.

Re: #20 I believe that would need a large D.A. policy discussion first, separate from this issue.

Though I will warn I would suggest the D.A. refuse to accept such a policy. The Drupal Community lost uncountable hours of possible contributions in the old system. The long term problem of "unable to find maintainers' can likely track some of situation back to those early policies.

I remember the vetting process. I would not want to bring the previous vetting process back. I think an open vetting process would prevent a backlog from forming. The important thing is for vetted status to be revokable.

Of course, the threshold to the creation of full projects being lowered is an important reason for this issue existing in the first place; the premise is, anyone can create full projects, so we don't need anyone to be able to create sandboxes anymore. If that changes again, the premise to this issue falls waway.

However, even with me being able to create full projects, I appreciate the ability to create a sandbox once in a while. Not having to come up with a short name (or rather, a unique short name that has not already been taken, with the added mental pressure of "I am now squatting this name, what if I'm not able to get it up to a reasonable status?") is a valuable feature to me. Having a low-threshold way of getting something up on Drupal.org quickly without having to worry about details yet is very useful.

What if it were possible to create projects on the GitLab side, in your own personal space (I think that's not currently possible)? What would be needed on the Drupal.org side would be documentation pages explaining how to do this, maybe how to get such code in your site projects. Support from Drupal.org to promote such projects - or maybe any arbitrary public Git repo? - to full projects would be a nice-to-have, but not essential; you could also have a documentation page explaining how to get code from a personal project into a full Drupal.org project (add remote, push to the remote, etc.). The same would go for some public surfacing of such projects on Drupal.org, e.g. a list on people's profiles (GitLab would then handle rendering the README.md on the repository page).

At this point, you could wonder what the added benefit is over pointing people to e.g. GitHub. Not sure, and maybe the documentation should acknowledge it as an option. It could lower the threshold for some, and I guess if we were to render a list of drupalcode.org-hosted personal projects on people's profiles, that would be a reason to stay on Drupal.org as well.

Not having to come up with a short name (or rather, a unique short name that has not already been taken, with the added mental pressure of "I am now squatting this name, what if I'm not able to get it up to a reasonable status?") is a valuable feature to me.

@eelkeblok Sandbox project are still squatting names. Nobody can create a full project whose name is User Moderation because there is already a sandbox with that name. That is the project name, but since the short name is supposed to derive from the name, nobody would be able to create a full project whose short name is user_moderation or usermoderation. (There should not be a project whose name is Dragon Warrior which uses user_moderation as short name.)

Not to detract from anything, so apologies ahead of time but will there be a change record and/or announcement about the deprecation of sandboxes?

The reason I ask is because it could catch some long-time folks off guard; having something concrete to share/point to about such a change might help spread awareness (I know I hadn’t heard about this until @catch had mentioned about the sandbox deprecation in a completely different issue (https://www.drupal.org/project/drupalorg/issues/3563839#comment-16388163 in case anyone is curious).

The deprecation is not official or planned for any specific time at the moment.

Unless we have a practical solution for existing sandbox projects, the complexity of maintaining support for them will remain.

The main reason for me to create a sandbox project is to create a project before I settle on a fixed machine name.
Once i go for full project, I will be polluting/squatting the `drupal/` vendor namespace.

I might push something as PoC, then ask my colleagues if it is a good idea (might go to our own Jira for review), then we decide on the final name or to drop it, if e.g. instead we do a contribution to Drupal core, or we split it into smaller packages, etc.

@eelkeblok Sandbox project are still squatting names. Nobody can create a full project whose name is User Moderation because there is already a sandbox with that name. That is the project name, but since the short name is supposed to derive from the name, nobody would be able to create a full project whose short name is user_moderation or usermoderation. (There should not be a project whose name is Dragon Warrior which uses user_moderation as short name.)

Now this is very odd, and we should change or rethink it.
Maybe when you create the sandbox, you can ask to "reserve the name for n months". After that it is free game.
This way people cannot snatch it out of your hands immediately, but you are also not squatting it forever.

So in the first case you want to upload a project and make it open source but don't want other people to use it

There is a big difference between "here is some code, do with it whatever you like" vs "Here is a project with a release plan and a BC policy."

Sandbox project are still squatting names.

This is specifically about the project title, those must be unique, in addition to the unique short/machine name. This lets autocomplete on project title fields work, without needing to think about node IDs. We have occasionally changed sandbox project titles to get them out of the way of full project titles.

I agree with the usefulness of having your own space for experimenting that doesn't pollute the drupal namespace. One use-case for such a module is to Apply for the permission to opt into security advisory coverage. You're creating a new module so that you can prove you can write good/secure code, but you might not want to commit to maintaining it for other users, since you're only making it for a kind of test/exam as evidence of your skills and style.

Maintaining a module with a time commitment for other users when you just made it for the application doesn't make sense. Not every application will be a contrived idea of a module; some genuinely have a module they want to add. But if you are applying to maintain an existing module, then you have to create a new module for no other reason than for the application for permission to opt into security coverage.