RFC: Archived projects should explain in their readme why they were archived

[Christoph Cullmann]

Hi,

On Sunday, December 28th, 2025 at 13:06, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:

> 

> 

> Am Sonntag, 28. Dezember 2025, 12:34:26 Mitteleuropäische Normalzeit schrieb
> Albert Astals Cid:
> 

> > I ended up in https://invent.kde.org/system/xwaylandvideobridge the other
> > day and I was wondering "Why was this archived?".
> > 

> > Most of our stuff gets archived because "It's old and no one cares", but
> > that means that if someone cares we would not mind unarchiving it.
> > 

> > Some other things (like let's say KF5 only frameworks and possibly this
> > xwaylandvideobridge) are archived because better technologies exist.
> > 

> > I think it would be good if from now on we added a small note in the
> 

> readme
> 

> > explaining why the project was archived and if there's possibility of
> > unarchiving it.
> > 

> > What do you think
> 

> 

> Documenting those two things would be nice to have, ++.
> 

> Instead of seeing to add that info to any existing README or README.md or
> creating new ones, with the risk of people still missing it out (who reads
> docs, even one with possibly lots of info) or potentially deleting old yet
> once again still useful info while editing such README, would like to offer
> an alternative:
> 

> Not sure where I had come across that, but for archived projects they set up
> a special branch with just a single README file, holding the basic info
> "Archived project, for reason A. If interested to revive, do B. Etc.". That
> special branch was set up as default branch.
> 

> So anyone navigating to the default repo web view or doing a default repo
> clone without further checks would be exposed to only that very README, so
> could not miss the state and the info.
> 

> While the old master/main branch then would not be mangled with any
> "archived" info, like also any latest release/stable branches would not need
> to be. And when someone adopts and revives the repo, they do not need to
> undo any "Its archived info" from the docs in the min/master branch.

I personally would prefer the note added just to the README.

That has a lot less steps to do and undo on the admin side of GitLab.
No default branch changing and Co.
But that is just my 2c.

Greetings
Christoph

> 

> Cheers
> Friedrich
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 343 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20251228/17435828/attachment.sig>