I like the idea of marking projects which are up for adoption. It will still be a mostly social problem to find a new maintainer, but given the scale of the community, just providing opportunities might already help quite a bit.
I already said in issue #1 that I would go for a simple approach and make the collection of meta data as easy as possible. In the end the most important information is the fact that maintainers declare that they are willing to pass the project on to somebody else. Could it work to keep that as simple as possible by just making that a simple yes/no flag?
Project meta data is already available at many locations, in the source code itself, in structured meta data files such as DOAP, in secondary meta data e.g. in information used for packaging or as part of the project data on GitHub. So for example for a project on GitHub information about the current maintainer, the programming language, a summary, and more could just be extracted from having the URL to the project. Or when pointing to a file such as a DOAP file, it also could just be read from this file.
Creating this meta data is not easy, especially if many people are involved which need to have a common understanding of what the fields mean (as I know from experience ;-). So relying on existing meta data would work around this problem and also have the benefit that it could be done centrally, so that a bit of work on that on the server side would make it easier for many on the project side. The less mistakes people can make when filling in data the better this will scale.
So when thinking about the idea my feeling was that it could be as easy as adding an ADOPTME file to the repo (and yes, I think poor unmaintained abandoned projects deserve a bit of yelling in the file anme to find a new loving maintainer, instead of putting that into a hidden file). The server could figure out the rest. And maybe it could be assisted by putting a simple URL to more meta data into the file or just a plain text with some more info.
These are my 2 cents.
I like the idea of marking projects which are up for adoption. It will still be a mostly social problem to find a new maintainer, but given the scale of the community, just providing opportunities might already help quite a bit.
I already said in issue #1 that I would go for a simple approach and make the collection of meta data as easy as possible. In the end the most important information is the fact that maintainers declare that they are willing to pass the project on to somebody else. Could it work to keep that as simple as possible by just making that a simple yes/no flag?
Project meta data is already available at many locations, in the source code itself, in structured meta data files such as DOAP, in secondary meta data e.g. in information used for packaging or as part of the project data on GitHub. So for example for a project on GitHub information about the current maintainer, the programming language, a summary, and more could just be extracted from having the URL to the project. Or when pointing to a file such as a DOAP file, it also could just be read from this file.
Creating this meta data is not easy, especially if many people are involved which need to have a common understanding of what the fields mean (as I know from experience ;-). So relying on existing meta data would work around this problem and also have the benefit that it could be done centrally, so that a bit of work on that on the server side would make it easier for many on the project side. The less mistakes people can make when filling in data the better this will scale.
So when thinking about the idea my feeling was that it could be as easy as adding an
ADOPTMEfile to the repo (and yes, I think poor unmaintained abandoned projects deserve a bit of yelling in the file anme to find a new loving maintainer, instead of putting that into a hidden file). The server could figure out the rest. And maybe it could be assisted by putting a simple URL to more meta data into the file or just a plain text with some more info.These are my 2 cents.