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
Danyl Strype
All Bobinas P4G content and data are available under the