Move issues from www.drupal.org to git.drupalcode.org

Just curious: if it will not save significant time/effort in maintaining Drupal.org, what is the purpose in doing it at all ?

It's not just issues, we will also get kanban boards, gitlabci integration and many more features that come out of the box by using gitlab...
Also, the management of issues (and comments) will be in gitlab, which will make drupal.org "lighter" (and faster too?) and we won't need to migrate these to the new version of d.o.

The new credit system has been mostly rebuilt already and is being tested.

I guess there are pros and cons no matter how you look at it tho.

Thanks for the answer. I guess I'm most worried by the issue stats and sparklines going away, as discussed on Slack.

For many years now, these have been amongst the most important indicator to site builders evaluating modules about the state of an extension they envision for their site, and losing those means losing a lot of value for that segment of the Drupal users/evaluators/auditors.

In my opinion it was a good decision to use Gitlab for a better management of git. Especially the Issue fork feature was implemented very well on d.o. But the Issue features and all non code data structures and user management in Gitlab are very limited compared to Drupal. Because of this I'm working on a Drupal based replacement and/or companion solution which will be also a d.o project when ready. And I like to add that I was inspired and proud about the fact that Drupal(.org) can do a customized issue management when I joined the community.

Some missing features or problems I see in Gitlab and can be solved with Drupal are more important for companies especially the need of data protection and time tracking for example which are less important on an open source project. So I will focus on the current and future needs of our community in this post.

Gitlab only provides a board view with drag and drop sticky note view like many others but Kanban is more. Adding a kanban view to project issues is something we can easily fix (I'm currently also working on it) if this really makes sense. here I have two concerns:
1. It's not in any case a good idea to just allow people moving tickets and change status by drag and drop. For this I'm working on a board which allows hookable checks before accepting a change for example to realize the kanban feature "Limitation of Work in progress". The board column logic in Gitlab is just based on simple tags which cannot get additional fields or permissions to avoid problems with wrong issue status.
2. There are many projects on drupal.org with many issues in the same status. This ends in huge columns. Is Gitlab already able to deal with this huge issue lists in Board view and is t still usable in this case?

> I guess there are pros and cons no matter how you look at it tho.

Yes, but there are is one very essential thing beside features. Gitlab is currently not a modular and cannot be extended or changed like d.o. So we are are now completely dependent of others to commit and rollout features we need or want even if we are able to code a solution by ourself in rails. So instead of a tool which can be changed to follow our needs we need to deal with workarounds like the automated link creation so the new issue credit system. It's already less comfortable for me that I now need to copy an URL for adding a related issue to another.

Here are some other points I'm concerned about:

• What about moving issues between projects which is actual part of official workflows? As far as I know "moving" in Gitlab means closing the old one and creating a new one. So we lose the ability to follow Issues without manual actions (of everybody interested).
• Using more roles and its permissions as the actual hard coded ones of Gitlab.
• Consistent Issue Status (our workflow) with a global (tag) id for all issues for example to find all RTBC issues cross multiple projects.
• Possibility to show more important community information in the layout like for events or funding.
• Show "Drupal Comunity Identiyt" via Layout like "Drupal" icons, colors. Gitlab has ver limited options to change theming.

These things are maybe already addressed and hopefully solved somewhere. So I would be happy to read more about it.