Responsibility of the maintainer to respond in a timely fashion..

[aschrijver]

Hi,

I just created a comment on another issue #718 (comment) stating frustration on awesome lists that have a large backlog of PR's that are waiting for weeks or months to be merged.

I would like to propose a change to the Code of Conduct and add something along the following lines:

• Potential awesome maintainers should be aware/warned that maintenance can be a time-consuming business, and they should be willing to spend it (within the boundaries of reason, of course).
• Awesome lists have gained traction, not only in open-source community but in broader IT world. It is used more and more as an authoritative source (well, that sounds a bit strange, given the laissez-fair approach it started out with, but still) in software selection and to proclaim new products, to raise awareness.
• Especially that last point leads IMHO leads to a new responsibility for the maintainer, namely to merge new entries within a reasonable timespan, or - if that is not possible for some reason - ensure there is another maintainer that can do the merging.

WDYT?

(PS And here I would like to state that this is not personal criticism on any awesome maintainer on the block, you are awesome together with your lists! I fully understand busy schedules and that time is scarce.)

[sindresorhus]

Potential awesome maintainers should be aware/warned that maintenance can be a time-consuming business, and they should be willing to spend it (within the boundaries of reason, of course).

I kinda agree, but keep in mind that it's open source and usually done in people's free time. That being said, they should at least be willing to add people to help maintain the list.

[aschrijver]

My point in case is that if an awesome list is truly awesome™ then it is most likely to deal with an exciting upcoming technology. Very active community, the coolest projects popping up all over the place. And some of these projects wait for 2 months before popping up on the list that is designated for it, when meanwhile the hype cycle is passing fast and people made their choice already (I am exaggerating a bit, but you get the idea).

An awesome list that is not regularly updated is not following the concept of awesome so to say, it deviates from the core idea. Therefore just like with inappropriate text, there should be code of conduct to help avoid a list of getting in this grey field of half-awesomeness.

Guess the tagline could be (no pun intended, rather a statement of 'brand quality'):

Are you awesome enough to become one of our time-honoured list maintainers?

[inputsh]

As a maintainer of a couple lists, I have to say that GitHub really doesn't provide me with enough tools to accomplish 0 PRs. Two of my biggest concerns:

• There is no way for me to preview the notification without clicking on it.
• If I click on it and don't act on it immediately, there's a huge chance that I'm going to forget that it was submitted. I cannot save it to act upon it later or something like that.

These constraints leave me with two options:

• Hope that the author of the PR is going to ping me after a certain amount of time.
• Manually open the lists I'm maintaining from time to time to see if I missed something.

None of these options are good enough, so by going with the second option, I sometimes stumble upon something submitted a month or two ago. In that case, I've probably accepted something else in the meantime, which results in merge conflicts, so now I have to ping the PR submitter and wait for them to respond, which sometimes happens, sometimes doesn't.

For these reasons, I'm against this change. I'm okay with removing lists that have like 25 unanswered PRs for months, but if there's one or two PRs that are not acted upon for like two months, I don't agree that such list should be removed.

[aschrijver]

On the issue of disappearing notifications I already send a request the 3rd of August to Github Support:

Hi Github team,

I could not find a feedback link, so assume this is the proper place for suggesting improvements to github.com

If you participate in many projects and therefore have a lot of participating notifications the notification disappear when you first read them. This might be from a mobile phone from the train. If you come home you have to go from memory to find those issues and PR's again and give a proper response.

The more active you are, the more of a problem this becomes. So now the best practice is either only read notifications if you have time to prepare a response, or carefully copy the URL and open in a new tab.

So an improvement would be either to have people explicitly mark their participating notifications as done / handled, or alternatively allow filtering on the activity log to see those notifications.

That was it, thanks!

And got the following response:

Hey Arnold,

Thanks for reaching out. As someone who uses multiple devices myself, I can see how that would be useful. I switched back to email notifications for exactly that reason.

I can't make any promises, but I have definitely added it to the feature request list and will share it with the team for consideration.

Regards,
Daniel
@danayel
GitHub Support

[aschrijver]

@Aleksandar-Todorovic Thanks for your feedback. I will remember to answer your other points tomorrow (its quite late now in Netherlands) and if I don't forget (the notification is gone now 😉 ).

Note however, that I am not in favour of closing a no-longer-maintained list down. That would sell awesome short, the technology and PR's are still relevant.

You could solve this by having the rule that a real awesome list maintainer must allow a second maintainer (maybe one from the list-of-lists maintainers) that is not involved in day-to-day merging, but takes ownership in the case of too long period of inactivity. If they don't comply they may not use the shield with logo, and are not included in lists-of-lists.

I don't know if one maintainer can disown another one with bad behaviour, just like you can reject misbehaved PR's, but that might be a sanction.

[aschrijver]

@danayel Is the Github feature request list you mentioned open to the public, as let's say a Github repo? I couldn't find it. Or is the form+mail-like way the recommended contact route?

[davisonio]

I think the best way to solve this is to ensure that there are multiple collaborators on awesome lists. If we find that all collaborators are inactive then either contact them via other means to see if they would consider adding someone else as a collaborator to help answer the PRs or start a fork and use that as the updated awesome list from then onwards (the latter has been done with awesome-sysadmin).

[aschrijver]

Hi @Aleksandar-Todorovic I didn't go to sleep, worked all night, and so didn't forget to return to your issue 😉 but there were not that many points I didn't already respond to, I now see. And @davisonio you are right in stating that would be a working solution.

But I would still like to see some of this discussion reflected in the code of conduct. That should not be that much of a problem. These are in the end 'just' a list of moral guidelines not judicial requirements..