Right now, if you don’t have notifications enabled for interests, then it’s likely to miss these messages, because you only see the messages link on your projects page (the envelope button).

New messages could be indicated somewhere in the navigation bar. (This would probably also include adding something like marking interests as read to only indicate the latest unread ones?)

• Project description (" is looking for:…") and repo description are mixed up
• Repo descriptions are html text and need to be rendered as such

In order to make it easy to receive the needed info with bug reports we should set up an issue template.

Expected Behavior

Project cards for projects with long names have a maximum size of the screen width.

Actual Behavior

Long project names mess up the layout for mobile screen size, because there’s no auto line breaks or some other overflow handling in place to keep the size of the project card at max of the screen width. So the project card extends beyong the page background, and allows for the whole page scroll horizontally.

Steps to Reproduce the Problem

1. Login and submit a project with a very long name
2. Search for it on a mobile screen size

Needs some CSS knowledge. I figure it makes sense to still see the full project name (no ellipsis or the like)?

When logging in with GitHub, the user's email can be one that is not active/working anymore.

However, we use this email to send messages and as the response email if a user send an interest message for a project.
In order to make sure the sender can receive a reply from the project maintainer, we should let users confirm their email.

(We already had a real case were a reply to an interested user was not possible due to an not available email address)

An alternative might be letting a user select/add an email to use for messaging after login with GitHub.

To fill the rather large gap between receiving project recommendations once a week and once a month.

This should be rather quick to do by adding a bi-weekly value to email_project_recommendations_values here:
https://github.com/adoptoposs/adoptoposs/blob/staging/lib/adoptoposs/accounts/settings.ex#L19
and adjusting some tests.

To provide maintainers (i.e. the person who submitted the project) with some best practices about the next steps after someone contacted them.

Not sure, which best practices that would be yet in detail.

Sth. like this comes to mind:

• not waiting too long to reply and also let people know if you have already found someone
• setting up a chat/call with the potential (co-)maintainer to tell them more about the project and learn how they want to/can help
• ...

Maybe someone has some experience with what works well to start the conversation with potential (co-)maintainers and on-boarding them?

Expected Behavior

Dialog for "Share this project" should display and let the user copy the link of the project

Actual Behavior

Dialog gets covered by box of next project. As a result, user is unable to copy the link. See screenshot

Steps to Reproduce the Problem

1. Go to Explore page
2. Click on the icon for sharing
3. Dialog for sharing appears

Please note that the last result on the page is not affected. On Safari and Firefox, behavior is correct.

Specifications

• Version: Chrome 85
• Platform: Macos Catalina
• Subsystem: -

In order to make projects that are written in multiple different languages (I figure this is quite some, if not most, actually) available for multiple language tags in the search, it should be possible to attach multiple tags to a project.

Maybe the main tags for a project can be auto-suggested and editable when adding a project.
Tags should also be freely editable afterwards.

Aside from the list of most-recently-added projects, I couldn't find a non-search interface. Apologies if I've just missed it.

I think browse/exploration-oriented views could add a lot of value for people who might be looking for projects to help. I think there are at least two main components to this:

1. A search-oriented interface entails knowing what I want to do already, but aside from searching for certain languages/dependencies, I'm not sure how many people will be able to find a project that really sparks their own interest by searching?
2. I hesitate on this, because it might discourage people from joining the smallest projects, and I'm not certain if prospective maintainers would actually care, but I can at least imagine that project statistics highlighting which projects are generating the most demand for maintenance might help direct effort towards need? (I'd hesitate to just privilege starts or forks, but some good metrics might be: the number of open issues/PRs, the number of issues/PRs opened since the last release, the total number of comments or unique commenters since the last release, and--of course--the number of people that have directly marked interest via adoptoposs in finding maintainers?

Expected Behavior

mobile view is "nicely" styled, e.g. ...

• either with a mobile menu to be onfolded or
• by a smaller button (short text) to fit all elements in one line.
• minmal solution: apply margin between logo and second header line.

Actual Behavior

search icon and github login button flip to next line without any margin applied.

Steps to Reproduce the Problem

1. open web page in mobile view (see attached screenshot)

let me know what approach you'd prefer and I can take care.

Expected Behavior

• When I send a message to a maintainer after filtering projects by languages, it should get sent and it should reflect in the Messages page under the "contacted maintainers" section.

Actual Behavior

• The messages are either not getting sent, or are not showing up on the messages page under the "contacted maintainers" section.

Steps to Reproduce the Problem

1. Click on "Explore" in the navbar, and filter projects by a language, for example TypeScript.
2. Select a project, click on the "contact maintainer" icon button, and send a message.
3. Click on "Messages" in the navbar, and then click on "Contacted Maintainers". The sent message does not show under this section.

PS: I've tried multiple times with different maintainers. I was able to reproduce it every time.

Update Quantum (which runs the emailing background jobs) to ~> 3.0 in order to get rid of the deprecation warnings.

See the Quantum Changelog for further details about the needed modifications.

…with a list all contributors of the project, for motivation and showing appreciation.

• Add a sentence or two to the CONTRIBUTING.md to encourage contributors to add their name & GitHub handle link to the list when doing their first contribution.
• Link to CONTRIBUTORS.md from README.md
• Add already available contributors (most recent on top) to the list when creating the file.

I only found it because I had the same idea, otherwise I wouldn't have known it existed.

It is a fantastically useful project, but if no one knows about it then it's not. In your blog post mentioned:

After I found that, on GitHub alone, there were more than 36,000 issues asking "Is this project abandoned?", I thought about how to tackle this problem. More than 15,000 of these were open issues. So, lots of projects need help with their maintenance.

So, how do we connect those projects with this one?

I would suggest a nomination feature, where people can nominate a project, and then others can vote on it to give it more visibility. I realize you already thought of this:

First, I thought it might be nice to have a dashboard that rates OSS projects by whether they needed help with their maintenance. When I had a prototype running after a couple of days' work, I found that it kind of worked but did not really overcome the problem of getting into contact with the maintainer. And when a maintainer was hard to reach when I needed support, it would already be too late.

So how are we getting in contact with the maintainers now?

A nomination feature could put some visible pressure on the current inactive maintainers (e.g. "look, many people want this project to stay alive."). I suspect many of the inactive maintainers aren't even thinking about those projects anymore, so expecting them to come here (without even knowing this exists) and submit their project(s) without a little nudge is unrealistic.

Maybe even have a notify feature, when enough votes have been cast for a project you can either tweet at the person (if their github has their twitter listed) with a link to the project nomination on adoptoposs.org. Another way would be to have a separate github repo for just issues that are autogenerated and tagged with the person's github handle.

There are other ways to get this out there. Maybe contacting large multi-part projects like GNOME, KDE, MATE, etc, that have many smaller parts that lack maintainers. Those projects will most likely know already which one of their smaller programs are in need of maintainers.

Another way would be to start with those 15,000 issues mentioned above, sort them by number of github stars, and then contact the top 100 or so manually.

Another feature that could be useful would be to try to lure the currently inactive maintainers back. Combined with the nomination feature, you could have a sort of pledge system where people can pledge to support the project financially (e.g. through Github Sponsors, Open Collective, Patreon, etc.) if they start maintaining the project again.

Obviously there could be some issues with people following through with those pledges, so those kinks would need to be worked out.

Perhaps it would be enough to get the maintainers interested again.

I also think the github stars and date submitted should be listed on the projects page.

Also, add the website name to the README. I know it's listed in the description, but it should also be prominently displayed in the README.

Anyways, that's my 2 cents worth.

Expected Behavior

I only see projects once (and maybe after a while again) in the recommended projects email.

Actual Behavior

Unless there were new projects added, the recommended projects will be the same over and over again.

Possible solution

Projects that were already picked as recommended ones for a user should not appear in the next emails again.
I.e. we need to store which projects got already recommended for a user and skip these the next time.
Maybe we can consider them again after a certain while, in order to make long available projects without interests still seen again (after 2-4 notification periods, maybe?)

Expected Behavior

Website to work

Actual Behavior

$ curl -sSLI adoptoposs.org
curl: (56) Recv failure: Connection reset by peer
$ curl -sSLI https://adoptoposs.org
curl: (35) error:0A000126:SSL routines::unexpected eof while reading
$ openssl s_client -connect adoptoposs.org:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 316 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Steps to Reproduce the Problem

See above

Expected Behavior

I should be able to log in.

Actual Behavior

Trying to log in redirects me to Github, where I authorize the application. The next page (still on Github) says it's about to redirect me, but it keeps loading. If I click on the manual redirect link, I am redirected to Adoptoposs, but it says "Authentication failed.", and I'm still not logged in.

Steps to Reproduce the Problem

Described above.

Specifications

• Version: N/A
• Platform: Firefox (latest) and Brave (latest)
• Subsystem: N/A

Let me know if there's anything else I can do to help debug this.

Until recently we fetched programming languages after every deployment from github/linguist.
This might lead to missing new programming languages when there wasn't a deployment recently.

So we should set up a recurring job that calls the fetch_languages routine automatically (maybe once a day).

Currently projects are immediately visible after repo submission. You can already remove a project, which entirely deletes it from the database, including all related interests for that project.

Maybe sth. in-between would make sense, to take off a project from the public search but still not lose the contact details of interested users.

I think Adoptoposs is a super idea and the website looks great!

Would it be possible to reduce the necessary GitHub permissions, though? Here's what I'm seeing:

Read access to public repositories is obviously fine. Write access is a little scary, and I wasn't sure why it was needed. The same goes to write access to personal user data. I'm also slightly concerned about read-access to private project boards, but I haven't dug into see if that exposes any proprietary information from corporate GitHub orgs that I'm in.

…to let users know that cookies are used, their data is being collected and will be used for certain purposes (as already stated in the privacy policy) and to get their consent to use the data.

Expected Behavior

Text does not collide with close (x) button.

Actual Behavior

Text collides with close (x) button.

Steps to Reproduce the Problem

1. delete cookies
2. open web page
3. check out cookie message overlay on the botton (screenshot)

please let me know any preferred solution (i.e. any css classes prepared I should be aware of?) and I can take care.

There's this message when installing hex dependencies:

basic_auth 2.2.5 RETIRED!
    (deprecated) Basic Auth is now part of Plug. Use Plug.BasicAuth

So we should follow this advice.

I'm not sure if this is a bug, on the roadmap, or something you've considered and not included for good reasons, but I was playing with the new explore interface and noticed search doesn't seem to include the project about/description (it appears to just include the project full_name, and whatever comment the maintainer supplied when submitting):

• https://adoptoposs.org/explore?q=&f[]=4 filtered by language shell, currently showing 1 project (odb/shml).
• https://adoptoposs.org/explore?q=style&f[]=4 filtered by shell, but searches for "style", which appears in the description but produces no search result.

I'm doing a little work this afternoon to set up an app that that hasn't had a release in 4 years. It seems to work for my purpose, but it makes use of a popular platform API and there are some open issues about pieces of functionality have become non-functional without significant hoop-jumping due to platform security changes.

I could see a sad dance in a lot of issue comments there, where people were wishing out loud that someone would fork and maintain the project (but, obviously, none willing/able to make the jump themselves). When I saw them, I thought of how many times I've seen an ASK HN thread that boils down to, "I'd like to work on a project for experience or resume-building, but I don't have any green-field ideas of my own."

I found your project while searching around to see who all is actively picking at this issue, but it seems like your flows/wording/UI are very focused on a project-owner finding additional maintainers. (I don't mean to suggest this is the wrong emphasis--I think stabilizing useful projects before the maintainer becomes completely unresponsive is both simpler and more useful for the OSS community.)

If you aren't already considering it, I think there may be additional value to add here with a flow for project users (or prospective users) to nominate projects that are (or appear) to be unmaintained. This task would probably need its own interface and rules/procedures since it's more uncertain/delicate than the owner seeking help.