Conversation
Notices
-
@cbowdon ae, same with choosing new user-facing apps for evaluation as potential replacements for common proprietary apps
-
It would be great if #GitLab and other code forges automatically marked projects 'dormant' or 'discontinued' after a certain time of no work
-
I guess there would need to be rough consensus on how long a project needs to go with no commit before these descriptions would be fair
-
Some standard for putting a #LuggageMark on project when active dev is moved to a different forge would be helpful too
-
@arunisaac really? Given that software runs on OS that constantly change (security patches etc), and often connects to networks that do too?
-
@xurizaemon see my reply to Arun Isaac https://quitter.se/notice/25203513
-
@xurizaemon @arunisaac say you're right, in that case lack of commits or the activity on the forge would mislead me into thinking "useless"
-
@arunisaac @xurizaemon what I'm getting at is a standard set of labels that could used across forges, to indicate the state of a project ...
-
@xurizaemon @arunisaac it would certainly require some careful thinking, especially when it comes to anything automated ...
-
@arunisaac @xurizaemon I'm just aware that the foam of started-then-abandoned itch-scratching hobby projects makes it harder to find stuff
-
@arunisaac @xurizaemon I'm pretty experienced at sifting through and choosing apps to us, but it still takes up large chunks of time ...
-
@arunisaac @xurizaemon I can only imagine how overwhelming it is for those newly concerned about software freedom post- #deletefacebook
-
@xurizaemon thus the thought that automation could help with abandonment or active dev moving to a fork ;) Most labels would be self-applied
-
@xurizaemon eg there could be a 'finished' label for programs that the author is certain won't need commits to stay useful ...
-
@xurizaemon program marked 'finished' would be excluded from any automated 'dormant' or 'abandoned' labels
-
@xurizaemon explain?
-
@xurizaemon sure, but a one-click way for a dev to mark a project they are abandoning as 'abandoned' would be useful, right?
-
@xurizaemon same with a one-click way for a dev to point users to a more actively maintained fork when they lose interest ...
-
@xurizaemon or a 'hobby' label devs can use to mark #ScatchMyItch projects that they know aren't yet ready for production use
-
@xurizaemon it's the same principle as when you put a license file in your repo, GH (and maybe others) supply boilerplate info about it
-
@xurizaemon it's about making the properties of codebases transparent so people (as end users or devs) don't waste hours trawling thru them
-
@xurizaemon I've found project homepages still live and giving an impression of active dev long after an abandoned project no longer works
-
@xurizaemon this is even more likely with repos in forges because they don't depend on someone paying domain name fees
-
@xurizaemon there is a legitimate case for automated labels because of this. I agree it would have to be designed *very* carefully
-
@xurizaemon "bug-free" is definetely not a label I'd consider useful. Did I suggest it somewhere? I don't remember doing that, but ...
-
@xurizaemon that's a bit harsh. #SourceForge suffered a few years of poor stewardship, but they improved. Some active projects still use it
-
for sure @lightweight, I'm not suggesting removing code ever, just a way of tagging it to indicate project status @xurizaemon
-
@xurizaemon hosted on SF is usually a case of a) old project that can't be bothered moving or b) project by greybeard who's used to using SF
-
@xurizaemon TBH I too have an implicit bias against code on SF, post the malware-in-downloads debacle, but I try to be conscious of that ;)
-
@lightweight @xurizaemon BTW it's a shame #Mastodon does such a bad job of reconstructing cross-platform threads (as do most fediverse apps)
-
@xurizaemon I may have lost the ability to distinguish between chatting and debating :{ Occupational hazard of being an activist?
-
@xurizaemon and I have been having an illuminating exchange on the pros and cons of automated codebase tagging
@lightweight
-
@xurizaemon @lightweight "surfacing measurable facts" yes, this. Like when a readme file in a repo says "Don't use this in production" ...
-
@lightweight @xurizaemon ... making that highly visible in searches, on the platform and off, without having to drill down to that ReadMe
-
@lightweight @xurizaemon the automation thing might be a distraction, standard labels (like standard licenses) is more what I'm driving at
-
@lightweight @xurizaemon I just can't think how voluntary labeling would help if a dev dies, or just walks away from their code in despair
-
@lightweight it's a new concept to me too, but @xurizaemon proposed it as a reason a project might still be active despite no commits
-
sorry @xurizaemon not intending to put you on the spot. We're all just #SpitBalling here :) @lightweight
-
@xurizaemon @lightweight awww, that makes me weirdly homesick. We've settled into our apartment in China and learning to love illiteracy ;)
-
@cbowdon @arunisaac @xurizaemon but surely responding to tickets/contributions with anything other than "yeah, nah" will generate commits?
-
@cbowdon fair point. Just so we're all on the same page, are you able to see the rest of the thread leading up to these comments?
-
@cbowdon it all started with an innocent #ShowerThought:
https://quitter.se/notice/25202906
-
@lightweight I don't want to get too specific about that here ;P But when I follow up with you and Christine about !kiwi #Greens stuff ...
-
@cbowdon I've noticed that quite often when projects get abandoned, neither their homepage, blog, or repo gets updated to say so ...
-
@cbowdon ... and too often unmaintained and increasingly unusable apps continue to get bundled in distros and their repos for years after