I can’t open a support ticket on this, because it doesn’t involve any specific project repo (one of the required fields), nor does it fit any of the three options for “Problem type” listed on the ticket form. But…
As the attached screenshot shows, my account is currently showing “Starred Projects (4)” on the dashboard, but the tab only lists three. Where did the fourth one go?
What was the name of the fourth starred project that has gone missing? We would need to know what it was called, so that we can see if the project still exists or not, or whether maybe the maintainer deleted it.
That’s the thing, I honestly have no idea. And I can’t think of any way I could find out, not being able to see the list of what exactly it’s counting. I assume it is a deleted project, but I couldn’t for the life of me tell you which one it was.
If a maintainer deleted a project, conceptually the count should drop as well, not? If a project isn’t there, I would argue my star should be deleted as well. There’s nothing to have starred. So, perhaps that’s a bug in the dashboard/star handling.
Found it: It’s Jens Lody / gnome-shell-extension-openweather · GitLab
Which is still there (and still starred by me), but archived and therefore, apparently, not visible on the dashboard. But then it probably shouldn’t be included in the count of starred projects, either.
I also can’t seem to close the open MR I have on the project. Attempting to gives me a 404 error.
Yeah when it’s archived it’s read only, so you cannot close it. I would suggest open an issue here related to the star count not decreasing in such situation: Issues · GitLab.org / GitLab · GitLab that way the devs can look at it, and fix or explain the reason.
Understandable, though it kind of sucks for neurotics like me who don’t like leaving “unfinished business” hanging around. When a project is abandoned I’d prefer to also close all of my open issues/MRs, personally. (I also have four open issues, same project.)
Though, the MR doesn’t show up in a https://gitlab.com/dashboard/merge_requests search for “Author = ferdnyc@…” (which does get the count correct, i.e. it doesn’t count the “hidden” MR) so I guess there’s no harm in it staying forever open-and-unmerged.
I’ll report the counting issue on the Dashboard list, thanks.
I guess would have been nice, eg: maintainer closes all outstanding issues, with a comment that the project is being archived. That would at least address your situation. Although that said, I’m not sure if issues get forked as well as the project. If so, then the remaining open issues could be handy to someone who forks the archived project, fixes the issues and release as a continued project.
I, like you, also prefer to have things closed off and not hanging around as old rubbish/trash 
Done: User Dashboard project counts include archived projects, which aren't listed (#374700) · Issues · GitLab.org / GitLab · GitLab. One of 44305 open issues, yikes.
In fact, in the course of reporting I created an example-of-problem project under my own account, as requested, and discovered that the bug affects “Your Projects” as well. So the report expanded a bit.
In an ideal world, perhaps. But since the most common reason for abandoning/archiving a project is “no time” (as was the case here), unless there was a one-click method of doing that, realistically I don’t see that happening. Or if it were an automatic part of the archiving process, I suppose
Well, that project actually was taken over (by Jason Oickle / OpenWeather · GitLab), but that repo was started fresh, not as a fork. Unless the original repo had been transferred over (in which case it wouldn’t be archived), I think having their issues/MRs migrated to some other project without their say-so would upset some users.
And that’s kind of the thing, isn’t it, about the read-only archival?: It breaks the user-controlled model for submitters’ content.
When a project is live, a user who submits an issue or MR is still in control of it. They can choose to close/withdraw it at any time, they can edit the details or push new commits… it’s still their issue, or their MR, despite being in another project.
But archival throws that all out the window, and says, “Sorry, you no longer have any control over this content you created.” (Though, I suppose I could still push to or even delete my project branch associated with the MR, so it’s not a total loss of control.)