Abandoned Projects

[jonobacon]

One of the issues outlined on Twitter since I shared this project is how we could deal with abandoned projects. In those cases arguably someone doesn't have write access to the project.

Now, a couple of thoughts:

• A simple (if drastic) solution could be to fork the project if it is genuinely abandoned. Obviously this is easier for projects on GitHub, but may be more complex elsewhere. It could then have the .adopt file added.
• Another solution could be to find someone with commit access to add the .adopt file. I suspect in most cases this would be possible.

Question though: should the scope of the project cover both unmaintained and abandoned projects?

There is certainly nothing stopping this - the maintained field could be switched to a status field with options such as maintained, unmaintained, and abandoned.

Thoughts?

[zettberlin]

I propose something like an "currently reviewed" field, that would indicate, that the project is not ignored and not mainained or revived either. I believe, that in a world of bazillions of applications that still do not meet all needs of the users it is most important, to find out how a project could help to provide a really new functionality to users. Plus it would also be important to find out, why actually some project was abandoned. In many cases, the answer would be: because the author has lost his/her interest/ does not have the time anymore etc But is some cases the answer could be: "Because bad design makes this code a dead end." There is much to be learned from abandonedware.

[jonobacon]

Interesting notion, @zettberlin. :-)

It sounds like you are thinking that the .adopt file could potentially shed some light on the reasoning behind why projects are abandoned, thus the data from the indexer could help improve how the overall adopt-a-project could work.

I like the notion of pulling out the reasoning why a project has been abandoned (e.g. run out of time, bad design etc).

I guess the challenge is gathering useful data in the .adopt file while also keeping it simple. Do you have any thoughts on what is the most important information to include?

[zettberlin]

I think, some tagging-mechanism could be adequate. As in: a very simple list of tags attached to the adopt-file for categorising and statistics. If there would be a tag like "bad design" other reviewers could simply vote to agree/disagree. That could lower the threshold to contribute and help coders to find projects, that are interesting for them, based on their level of skill or their affinity to a certain challange.

Think of: Mary wants to do something real in Python the first time, so she would search for tags like "py", "minimalistic", "promising" and exclude tags like "complex", "bad design" etc The projects would show some tag-cloud or similar visualisation to make it easier to search intuitively.

That is a lot of work but not too complex, methinks. And attracting active coders and users seems to be vital for something like a software-orphanarium ;-)

[zettberlin]

Back to topic. The reason for abandonment could be a tag too, or better: a combination of tags, weighted. Such as:

no time (4) too complex (4) little user feedback (2)

The summed numbers have to be 10.

Of course an elaborated essay on the topic can be much more precise. But we all know, how hard its seems for coders to write great volumes of CDATA ;-) And the elaboration could be done in the discussion, triggered by the abstract reasons and their weighting.

[jonobacon]

Thanks, @zettberlin.

My inclination is that we switch maintained to be status and this can have the following options:

• maintained - the project is actively maintained, thus not indexed.
• unmaintained - the project is worthy of active maintenance but needs a new maintainer. When using this field it presumes there is a person to provide a handoff.
• abandoned - the project has been abandoned and there is no person to provide a handoff.

This is my initial thinking but I am also pretty unclear of what I think when it comes to the difference between maintained and abandoned - I wonder if there is much of a difference?

As for the reasoning behind the current status of a project, my thinking is that we just provide a new field:

• reason - a textual summary of the reason for the current state.

This will bypass the need for tags.

Thoughts, folks?

[zettberlin]

If my poor English does not fool me, something, that is maintained is not abandoned. Unless you think of a "maintainer of the abandoned", who may introduce interested coders to the project and answer further questions whithout actively developing the project. In this case a abandoned project could be unmaintained(no maintainer will answer questions etc) or maintained. Thus maintainance would be a sub-status of abandoned(abandoned with or without maintainer). A field to write down a reason would be absolutely needed with or without tagging-function.

[jonobacon]

My feeling is that unmaintained means that someone still keeps an eye on the project but they are not using it. I think abandoned means that someone is not interested in doing any work on it.

[cornelius]

To me the value of the adopt-a-project idea is in declaring the intent to pass the project over to somebody else. There certainly are tons of subtle differences in what that means, but does that really matter? If the project finds a new maintainer all these questions are secondary. There will be a new situation, hopefully with new energy which overshadows all questions of abandonment or unmaintainedness.

The discussion already shows that it's not easy to come to clear and universally shared definitions, especially on an international level, where people might have very different background in terms of language and understanding of English. To me a simple "yes, please adopt me" flag would already be enough. Clear, simple, and direct.

And actually I would also not try to collect meta data about the project in the .adopt file. But this is probably a separate topic. I'll create a separate issue for that.

[jonobacon]

I think you are right, @cornelius. It feels to me like we should just stick with a maintained field for now which can be set to yes or no.

[luisbg]

I find the spirit of this project points in a great direction. Too bad it doesn't seem to have much activity, may I suggest adding a .adopt file to it? :stuck_out_tongue:

Now seriously. Having leaders and maintainers accepting and acknowledging, for whatever reason, they are not doing much with those projects anymore to be the hardest step to overcome. After that it would be a community tradition to add an .adopt file to the project.

Since I believe there are really cool unmaintained projects out there and a lot of excited people looking for projects to help with. How about we start by trying to create a "take this over please" culture, step by step.

Would generating a list of unmaintained and adoptable projects be a good start? This could be a resource for people to look for projects to take over. Then we can start asking those projects to add the .adopt file. I'm expecting a lot of dead email addresses, so that could be a second list of unmaintained projects without a responsive contact.

As a reference, Lua has such a list of unmaintained projects up for grabs: https://github.com/Etiene/luatakeme