What should we do when code for a project is migrated off of Drupal.org?

I think in the instance where a module is pointing to an external code hosting provider, it should be unpublished. It is free advertising.

I think the better thing to do here is flag them as an abandoned project, remove the links to the external hosting code. Close the issue queues on them and if someone else wants to take over the modules they can.

In the cases were the git repo was destroyed, we should revert to a known version.

--edited for a typo

I agree with #3, unpublishing them is confusing for users who get a 403, and abandoning them can free up the namespace.

I think #3 is ok. I think we now use the term "unsupported" rather than abandoned, and that gives the opportunity for a new maintainer to take over.

It's long been a goal of the Drupal community to keep code on drupal.org, and this is in keeping with that goal.

I do not think that we should unpublish projects or releases except for security reasons, and do not think that we should delete repositories.

I like most of #3 but am less sure about these two items:

1. Close the issue queues on them and if someone else wants to take over the modules they can.
2. In the cases were the git repo was destroyed, we should revert to a known version.

closing/opening issues is a lot of noise and work. Let's leave the issues be until someone decides to do something with the namespace.

I think only a person who is taking over a project should change files in git. If nobody wants to take it over then having the files deleted is probably actually the right thing.

I agree with greggles #6, I clicked submit too soon. IMO only the owner of the project should be changed, and probably an explanation of the change added to the project page and the issue queue.

I'm on board with 3-- I don't see how destroying a git repository is in any way congruent with http://drupal.org/dcoc#stepping-down.

I tend to see it more like taking you toys and stomping off.

It's a ridiculous example, but if earle decided to host views on somenewdevhub and destroyed the git repo would that really be ok? really?

Just to calm this down... It's not possible for an ordinary user to destroy a git repository. The tags are there, the branches are there. The entire history is there. Making a commit in anger is not at all the same as destroying a repository.

good point-- I don't think anyone was actually referring to 'destroy' in the 'it's completely gone and can't be recovered sense'. "reverting to a known version' as described in #3 implies that it wasn't actually destroyed.

My feeling is leave the issue queue alone but ensure the latest code that should be in there is there to make it easier for someone to step in and take over.

but ensure the latest code that should be in there is there to make it easier for someone to step in and take over.

Thank goodness, since we use git and have backups, this is always the case.

Oh, I realize it's not totally gone but I mean revert the "removal" commit so that the code is where it is expected to be and not hidden behind the vandalism.

I would prefer to leave the git repos as they are

Could you clarify this bit? If the last act of the maintainer was to do a commit that "removed" all code (I know it's not literally removed) do you want to leave that as is or revert it back to the state before that act?

If the maintainer has not attempted to "remove" the code then I agree to leave them as they are. My only thought here is that undoing any last minute vandalism leaves the project in a better state to be moved into by someone new.

Yes, I don't want to undo the most recent commit of the former maintainer.

Mainly, because I am lazy and don't actually know how to do that in the best way...

Are *all* of these projects listed affected in the same way, or are we talking about one particular project? If it's one project I'll be happy to take a look at it, see if a simple revert is all that's required, grant myself privs, do the revert, and take away my privs.

The issue summary doesn't really explain this.

I think all of the are affected in the same way, I did only check 2-3 though. There's also one that is missing above.

@rfay: Also, I think this is important for more than just the projects that triggered it. Would be good to have a general policy in place. So that's great if you can fix these but we need to know what should be done moving forward if it happens again because I doubt it will be the last time anyone decides to take their toys and go home.

I agree this is about policy.

Note that a policy issue covering some of the same ground is in the governance queue, #1507404: [Governance] Review policy for projects without code

The policy has been around for a while (october 2010 is the first revision on that node), though now we've got it super duper triple-stamped from the governance queue.

I think we should not revert the removal commit. If somone wants to become the maintainer they should do that. Otherwise we breathe new life into projects that maybe should really be unsupported.