[policy, no patch] Projects older than x months with no code are purged (namesquatting)

If we are going to tackle this we should think about broadening it to more than just empty projects. For example, if a project has code in it but has been sitting around for years with no full release, should it be demoted?

as DamienMcKenna said, some similar proces to 'demote' projects to a sandbox, or remove the namespace from unsupported modules would also need some sort of possibility. In the case of a 'module attempt' which seems to fail, and gets unsupported, without a new maintainer taken over. (personal example: #2403063: Demote features_civicrm back to sandbox). We could make a list of projects which will get 'namesquatted' in x months, to warn users of the module, they have to reinstall the module from te sandbox or apply to maintain the module further.

A bit more aggressive (perhaps out of scope for this issue?):
No release and no code for 6 months.
No release and no commits for 12 months.
No stable release and no commits for 24 months.

Why not just make a process through which someone can request a namespace that factors in these things rather than make it automatic? I still have hopes of doing Artesian some day but the only code is in a sandbox because it never made it past the experimental phase. I'd hate to see the project page just thrown away by an automated system when no one is even after the name. If someone requests the name, well, then, I'm on the spot to either commit to working on it immediately so I can justify keeping the name or letting it go. But at least then it would be for a reason and not because an automated system is going to dump it.

...rather than make it automatic?

There are two benefits to having some amount of automation. 1. Some people will not know or feel apprehensive about putting in a request to basically demote someone else's project. 2. We need to try reducing the amount of clutter in the project space.

@DamienMcKenna I think I was unclear. What I meant was:

A project has no published release and has been without code for 6 months.
A project has no published release and has not had commits for 12 months.
A project has no stable release and has not had commits for 24 months.

Since Views has a stable release, it would not be affected by any of my suggestions. My motivation was to get rid of all the projects that has started, but the owner lost interest before he could finish.

@Michelle there are changes on the way that probably will let sandboxes have "full" project pages. If I have understood the proposal correctly, that will probably be the best place to start developing modules in the future until they are ready for an initial release. Then you promote the sandbox to a full project.

The TWG discussed this in our meeting today (sorry for the slow response, we're trying to improve in timeliness of our replies).

In general, the Technical Working Group wants to ensure that any policies we create or new tools we recommend are aimed at solving well known and clearly stated problems. Anecdotally, we have not observed a lot of problems with junk or namespace squatting projects.

In comment 8 Davidhernandez brings up two interesting questions:

1. Some people will not know or feel apprehensive about putting in a request to basically demote someone else's project.
2. We need to try reducing the amount of clutter in the project space.

We are sympathetic to these concerns but would like to see some evidence in support that these are problems before making any policy or recommending that the DA invest in any tools to resolve them.

I might add that we do have a means of handling these situations today, in that anyone wanting to claim a (perceived) name-squatted project can do so under the existing Abandoned Project process.

But this is just as much about clearing out all the empty/abandoned projects cluttering the searches. Not necessarily because someone wants to claim the project names.

I didn't get that impression from the issue summary ... I read that as being a side benefit, as opposed to the primary driving factor behind the proposal. Perhaps some metrics as to how many actual projects without code are floating around out there would help sway me, but right now, I don't see the value proposition as high enough when balanced against the development effort and risk of false positives.

It could very well be that I put my own motivation in here, that was not part of the original issue. In that case, I apologize for the sidetracking. The original issue only targets projects with no code whatsoever, while my suggestion about including modules that never reaches stable releases will probably seem too extreme for some. I guess it boils down to wether we want some automated cleanup to prevent abandoned projects from lying around indefinitely.

After doing a module search for the string "entity" sorted by last release date and playing a bit with the pagination my results are:
- 1874 modules with releases.
- 80 modules without releases.
So roughly 4% seems to be without releases. And this number does not include modules that only had a dev release, of which there were quite a lot (and which my suggestion include while the original issue do not).

From #9:

A project has no published release and has not had commits for 12 months.
A project has no stable release and has not had commits for 24 months.

Discussed further on the April 1st TWG call.

As a matter of policy, we do not advocate unpublishing contributed code posted on Drupal.org, except in exceptional circumstances. While we aren't likely to cause anything as big as the left-pad/npm issues last month, we can't know for certain whether there is anyone depending on the existence of that repository as part of their workflow, even if there are no releases, or it's a module that isn't used by anyone else.

As to the first bullet point in #9 (and title of the issue):

A project has no published release and has been without code for 6 months.

As mentioned in #11, the TWG is leaving the issue as postponed pending further evidence of namespace squatting being an issue on drupal.org

In the meantime, we recommend that both scenarios identified in this issue should be dealt with via the existing abandoned module process.