Code Page Contribution Guidelines

[carolstran]

With the Code page, @Urigo brought it up in #768:

Who decides on which libraries to merge in and how do we order those tools?

Initial suggestion would be - Creating a standard using something like - (Github stars, Commit volume, Latest commit which is not renovate/bot) and use this standard to both decide if to include a library or not (or even remove) and to order the already included libraries.

AFAIK we’re putting non-essential editorial changes on hold until the Gatsby migration (#875) is complete, but it’d be great to decide on a process or guidelines for this. Not sure if there is a working group or another way to move it forward.

cc: @IvanGoncharov

[dosco]

I don't quite agree on pausing this whole list indefinitely to come up with some arbitrary rules. Sometimes good enough is better than perfect. The value of this list is its breadth and transparency. Instead of gatekeeping why not allow the community to vote something out if it does not fit. If you say decide on going with stars then you could inadvertently prevent small upcoming projects from getting highlighted. Commit volume does not work either I've often seen go libraries being solid enough and focused on a small but important thing to not need constant updating. I feel if it has something to do with GraphQL it should be on this list.

[burner]

I agree with @dosco whats the point of having a open standard and a community if it is not a community. Feels a bit like https://youtu.be/RGxbaxviRVw?t=25

[carolstran]

I don't quite agree on pausing this whole list indefinitely to come up with some arbitrary rules.

Whoops that was a miscommunication on my end - merging anything to the list is only paused until after the Gatsby migration (afaik lol I'm still new here). But this topic of what gets merged and how the list is sorted has come up in several places, which is why I opened this issue!

I completely agree with you @dosco - and I see having a guideline or standard defined as a way to avoid gatekeeping. That way, when PRs are open, those with write access can merge/close PRs accordingly rather than having them open and in limbo forever (which is the case now). Also then we can better define contributing guidelines for folks looking to add their tool to the list and make that process more explicit.

My thinking is like... list everything in alphabetical order, merge suggestions that come in, take things out when people flag them as out-of-date/not maintained 🤷🏼‍♀️

[mike183]

My thinking is like... list everything in alphabetical order, merge suggestions that come in, take things out when people flag them as out-of-date/not maintained 🤷🏼‍♀️

This sounds reasonable, it's also worth considering that some items on the page (especially in the "Services" section) don't actually have public repositories, so it wouldn't always be possible to apply standards based on Github stars, commit volume etc.

[burner]

I agree with listing things alphabetically. Not so sure about the stars.

Coming from purely selfish position, I'm the creator and maintainer of the @dlang implementation of graphql server and compared to JS D has like two users, I think we shouldn't rank by stars.

[jeggy]

One site that does something like this, which I really like is this webpage: https://kotlin.link/ they have put everything into categories(which could be Server Libraries, GraphQL Clients, Tools, Services and More Stuff in this case) and in each group they sort by stars. And on the top they have versions which would be programming languages here.

This list is still controlled by the community via Pull Requests.

[saihaj]

I feel like we should combine a Reddit or StackOverflow style where community upvotes/downvotes packages with a combination of defined rules as @Urigo mentions in #768 (comment)

[8bitreid]

I think code owners should be the ones to decide what goes, but I think the community should add what's out there.

[Urigo]

As we are actively working on a possible solution here, maybe it's a good idea to move some of the discussion there and get feedback from everyone here on that PR?

[orta]

OK, now that #936 is going to be merged soon - here's what I think should be the guidelines for the code page:

Adding Something

Most cases:

• We accept any PR which adds a new library, tool or service to the code page
• We ask that any library includes a few paragraphs for markdown describing usage and offering a chance to let people grok the project priorities.
• We are totally OK with people adding new languages etc

If it isn't a library, tool or service - then it could go into the community section. If it doesn't fit in any of these cases, then ping me or Ivan and we can figure out if/where it can live.

Removing something

Things to remove:

• Services which don't work anymore
• Code repos which are archived
• Projects declared to be abandoned by their maintainers
• Any link which 404s

If a project hasn't had a release in a few years, that doesn't necessarily mean that it's not working. We should rely on a pretty concrete signal before removing something.

[carolstran]

I like what you've suggested @orta! My vote is that we add these points to the contributing guide and then close this issue 😁