Select Topic Area
Product Feedback
Body
Apparently around early this May (ref) GitHub changed the way contributions show—or more precisely don't show—up on profiles. For over 10 years starring a repository you had contributed to (with the same email address etc. as on your GitHub profile) would make it show up on your profile, but this isn't the case anymore. The linked documentation commit did not explain any rationale for the change and "Update < file name >", the default commit summary, fails to address why such a deliberate, breaking and unwanted change was made. The linked pull request does not appear to exist or at least be public.
For some personal context, i.e. why I'm not happy about this change (copied from the aforementioned commit's comments section):
I'm a MediaWiki developer (you know, "that Wikipedia software"). The MediaWiki software and most of its extensions and skins are canonically hosted on the Wikimedia Foundation's servers, at https://gerrit.wikimedia.org, and most of them are also mirrored on GitHub. In the past, starring a repository enabled MediaWiki developers, whether those working on the core software or some obscure, site-specific extensions etc. to have their contributions show up on their GitHub profile, even if the canonical development happens elsewhere and thus no GitHub forks etc. are directly involved in the development process. (NB: some of the Wikimedia Foundation's paid development teams do use GitHub as the canonical repository for their source code, but that's still the exception rather than the rule.)
Now starring a repository is apparently...the equivalent to a mere public bookmark and nothing else?
If you were to look at my GitHub profile right now, you'd be easily fooled into thinking that I've not done anything anytime recently. But if you know where to look, you'll find that in June alone I've contributed to six MediaWiki-related repositories (which, on GitHub, would be @wikimedia/mediawiki-extensions-SocialProfile, @wikimedia/mediawiki-extensions-LinkFilter, @wikimedia/mediawiki-extensions-CreateAPage, @wikimedia/mediawiki-extensions-UserStatus, @wikimedia/mediawiki-extensions-MiniInvite and @wikimedia/mediawiki-skins-GuMaxDD; I'm the maintainer of these and a few other related extensions and skins for the MediaWiki software). One could, in my biased opinion, claim I've been somewhat productive in June alone! But this isn't showing up on my GitHub profile and it's making me very sad. :-(
Given the immense popularity of Wikipedia, and by extension, "that Wikipedia software" a.k.a our beloved MediaWiki, I feel like it's safe to say I'm not alone in this. This feels like a surprisingly big change that went rather unannounced and had a lot of people wondering why this happened and above all, what, if anything, can we even do to fix the problem and have our FOSS contributions show up on our GitHub user profiles again.
I'm also affected by this change. The commit history for those repositories on GitHub are linking those commits to our profiles, but they don't appear in our profile activity.
0 replies
Agreed, this change should be reverted. Makes me wonder if it was unintentional, in that this useful side effect of starring was forgotten and accidentally erased in a refactor.
0 replies
This seems very unfortunate, especially for Open Source developers. Not everyone is in a strictly defined 'Team' (we don't all work for Microsoft) and nor are all our contributions made on GitHub, it is an open source world after all.
I suspect this was done mostly to prevent spoofing and squatting of contributions via unclaimed email addresses or something? Or were there performance problems that led to this decision ?
Is there not some better or alternate way we can facilitate this ?
1 reply
This seems very unfortunate, especially for Open Source developers. Not everyone is in a strictly defined 'Team' (we don't all work for Microsoft) and nor are all our contributions made on GitHub, it is an open source world after all.
Amen to all of this. Wish I could "upvote" this comment more than once. 👍
I suspect this was done mostly to prevent spoofing and squatting of contributions via unclaimed email addresses or something?
Doesn't really explain why us with a confirmed email address are being "punished", does it now? Furthermore, email address may and often will change over time, but it doesn't really matter e.g. from a copyright perspective - changing your email address does not invalidate your rights as an author to your past work. :)
And MediaWiki itself has the whole SVN-to-git migration as a separate yet related issue: people were auto-assigned < SVN username >@users.mediawiki.org "email addresses", though 1) said email addresses do not exist and never did, and 2) their USERINFO file might've specified a (different, actually usable) email address.
I think, but I'm not sure, that in the past on GitHub adding the < SVN username >@users.mediawiki.org address did allow you to claim those commits.
Or were there performance problems that led to this decision ?
If only there was a place where the author or authors of a patchset could explain the motivation behind the change(s) instead of merely naming what file was updated... 🤔
(I really do have a thing against the "Update < file name >" commit message, it's genuinely useless as it doesn't describe the motivation for the change; version control systems already provide you with a way to see what file or files was/were changed...)
Is there not some better or alternate way we can facilitate this ?
Perhaps this request would fare better if it was coming from the Wikimedia Foundation instead of a random developer. I don't know, but given that the WMF (AIUI) has contacts with Google and such, it'd make sense that they'd have a contact person at GitHub or at least would know someone who knows someone else etc.
Regardless, I'm somewhat surprised by how:
- this wasn't really announced anywhere (or maybe I missed the announcement? Don't think I'm the only one, though.),
- the change impacts users retroactively; IMHO this is pretty much the equivalent of if a Wikipedia article contained a link which would get added to the spam blacklist, and then upon that addition taking place, the link would magically "vanish" from the page histories as if it was never there to begin with; thankfully that's not how things work at Wikipedia and e.g. old versions of content pages display the content from that precise moment in time!
- no-one from GitHub has yet commented and explained their take on this; making code and documentation changes takes always takes effort and thus has to be intentional, whereas not doing anything usually doesn't take much. It seems highly unlikely to me that this was an unintended side-effect of some other change or otherwise not deliberately planned, given that the documentation was updated and all. The requests for more info on the documentation commit were and remain unanswered by the people who could clarify matters.
the lack of explanation feels unintentional - but in any case, bad move. this makes people look way less active 😞
definitely reconsider.
0 replies
Hi all! 👋
Following an incident on April 24th, we made the decision to remove starring a repository as a way to get contributions in contribution graphs. Unfortunately our investigation found this feature has recently started impacting our platform's availability, and implementing a safer version of it that behaves consistently for all users is surprisingly nuanced and difficult. We recognize this has caused frustration and we apologize for not communicating the change sooner.
We are unable to re-instate this feature at this time but we sincerely appreciate you taking the time to share your concerns.
As a valued GitHub user, your feedback in this Discussion space, along with appropriate tags and examples, plays a crucial role in shaping the development of GitHub. While we can’t guarantee immediate action on every piece of feedback, please know that we are attentive to your suggestions and continuously strive to enhance the GitHub experience.
2 replies
While this probably isn't what I or many others were looking for, I can definitely say that the explanation is much appreciated, so thank you for that! 👍
@ebndev but wouldn't creating useless forks just to make contribution count add up in the total storage taken? A fork you're now forcing users to make would take a lot more space than a star would.
@mary-kate Isn't the workaround that you fork each of the repositories you have previously starred? It looks like that should still make your contributions show up?
1 reply
Indeed, so I've come to understand; but as you said, it's a workaround instead of a proper fix, i.e. better than nothing but not really ideal. Plus it always seemed both wasteful and pointless to me (although I guess it's nowadays only wasteful, not really pointless anymore since it's apparently the only way to properly populate your profile if and when you can't be added to an organization etc.).
maybe one can tackle it different? wikimedia foundation should offer hosting any source code not only their own, it is human knowledge. this would address multiple challenges wikipedia faces nowadays. first, open source code is like wikpedia ifself core training data for AI. second, wikipedia has loyal followers, but ageing. open source code will continue to be produced by young persons. third, wikipedia traditionally has difficulties to innovate its own source code base, given its followers are text persons and not coders. hosting source code brings developers closer.
0 replies