Dear fellow OKFN-ers! I have been receiving security-related warnings from GitHub about various legacy projects, and this morning decided as part of my professional duty to set four of them to Archived mode I have checked that in each case there was no activity in several years and that the websites were offline. They are:
They are each terrific projects, and the message I would like to send out with this is “badly in need of maintenance! be careful with this code - contact us first if you want to use it!” Please let me know of course if you disagree with any of this.
There are dozens of other projects in similar condition across my various organizations. Do any of you have a good clean up strategy, perhaps including an appropriate virtual graveyard for initiatives we want to remember, but still leave firmly in the past?
As a lapsed maintainer of publicbodies, I think this is for the best. I’d love to revisit some of these at a later date but we should focus on security for now.
I agree we should stop services that have standing vulnerabilities but people haven’t had time to work on it for a while.
On the other hand, perhaps, projects that have both a dataset and a front end (e.g., dataportals.org, publicbodies.org) should probably separate those concerns. Datasets don’t have vulnerabilities in the usual sense, even though they can get quite outdated to the point of being of little use. But those are different problems that could be handled in a different way on each case. What do you think?
In the case of Public Bodies, I have been meaning to update the Brazilian data for a while, maybe I can get to do it in holiday time.
Great perspective, @herrmann! You’re right that the datasets with the dataportals.org and publicbodies.org projects have a lot of uses and should be separated/maintained even if the front-ends are in need of patching.
Thanks Tod and Augusto for the comments. I’ve un-archived okfn/publicbodies since it sounds like there’s clear interest from both of you to brush it up and added a “needs maintenance” issue with links to this thread to the other three.
Something else we might try is a hacktoberfest-like tag on all projects that could use extra attention (but not too much attention) from the community (Open Data Day!)
One other thing of note, in addition to GitHub’s archiving there is the option of moving the repo to:
Simply moving the repo does not disable the automatic maintenance notifications. Just archiving does not clean the repo of out-of-date projects. There are pro/cons to both, of course.
I would be really happy if we could keep working on the dataset for public bodies in Sweden. Long time since we updated but we have some neat updates since last time. It would be nice if it could conform to DCAT-AP-SE 2.0.0 and be harvested to the national Swedish dataportal since no one has complete overview over public bodies in Sweden and an open source dataset would help. So I agree with disconnecting front-end and back-end datasets to keep datasets alive but perhaps making them visible on dataportals instead.
Nice suggestions, @mattias ! We already have an issue where we discuss improvements to the data model. Perhaps you could weigh in your proposals there. I had already mentioned the Core Public Organisation Vocabulary as a reference there. I think DCAT is a vocabulary more appropriate for describing datasets, rather than public bodies. But we should continue this discussion there, as it pertains more to the Public Bodies project itself, and this topic is about the maintenance of stale projects in general.
I have checked that in each case there was no activity in several years and that the websites were offline. They are:
and added a “needs maintenance” issue with links to this thread to the other three.