Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Removing 3rd Party Recommendations from Expressjs.com #105

Closed
jonchurch opened this issue Feb 29, 2020 · 10 comments
Closed

Removing 3rd Party Recommendations from Expressjs.com #105

jonchurch opened this issue Feb 29, 2020 · 10 comments
Labels

Comments

@jonchurch
Copy link
Member

jonchurch commented Feb 29, 2020

Currently on the express site there are a few places which link out to 3rd party sites/blogs, recommend content, list companies that use express, etc.

As this project has grown over time, having something listed on the community site is fairly attractive, as an official nod more or less from the project (even though the disclaimer says otherwise). At the very least I'd assume it's a juicy SEO bump if you're writing about Express (I haven't seen any nofollow).

Part of opening this issue is that I don't know how to fairly review submissions to these parts of the site, or justify their inclusion/exclusion since we have invited folks to submit their PRs.

There hasn't been much volume of PR's to add things to these lists lately (not since I started triaging a few months ago at least) but I wanted to start a conversation about these sections.

For reference here are some open PRs: expressjs/expressjs.com#1110 expressjs/expressjs.com#1097 expressjs/expressjs.com#1088 expressjs/expressjs.com#1079 expressjs/expressjs.com#968 expressjs/expressjs.com#950

I've reclaimed the #community contribution label to track these for now (it had 2 resolved issues associated with it prior).

Prior Discussions

The most comprehensive discussion I found about this prior was this conversation around reviewing middleware prior to inclusion.

This topic also came up in an issue about dead links (comment from @wesleytodd:

This is not a judgement on the package, but I would like to see the express documentation have less documentation on third party packages. Today there is a ton of outdated stuff which was added years ago, and I would like to not make it any worse. I think we should consider moving stuff like this into an "awesome list" format instead of it being on the express website. Thoughts about this direction @jonchurch?

Also see this issue with @crandmck and @wesleytodd discussing company logos, specifically wes:

... this is one of the issues I have with showing company logos in the website, so do not take this as personal feedback. BUT, how are we supposed to know you represent this company?

and @crandmck response:

... At this point, I agree we should remove [companies using express] page, for the reasons you cite (maintenance, inability to ascertain authenticity, etc). Are there any arguments for keeping it?

My Opinion

Personally I don't think there's anything wrong with linking out to stable resources when necessary. Ideally, all the relevant content needed to understand Express would be part of the documentation and maintained by the community itself, which I think we are basically at that point already.

Proposal

I think there are a few parts of the site that can be removed, like companies using express, and open source projects using express.

Other parts of the site that ask people to open a PR to have their article/project/etc included in a list could have the invitation removed, pending a decision about whether to keep those lists.

@dougwilson
Copy link
Contributor

Thank you for opening this for discussion and I think I agree with you.

Part of opening this issue is that I don't know how to fairly review submissions to these parts of the site, or justify their inclusion/exclusion since we have invited folks to submit their PRs.

Yes, this has been the main issue, in my eyes. We don't want to end up inconsistent with the acceptance or rejection of these if we can help it. I'm not saying we can always be perfect, of course :) but many times when someone opens a PR for this, they are doing it with the intention to be accepted, so are highly likely to question / scrutinize a rejection of it.

Perhaps we can, assuming we continue to accept these, have some place to list guidelines. It doesn't need to be complete nor locked in stone for all time. But can (1) give better confidence if someone is triaging an issue and thinks it should be rejected if there is a written policy that matches the rejection reason and (2) gives the submitter the opportunity to know ahead of time if it would be rejected based on a written rule.

Personally I don't think there's anything wrong with linking out to stable resources when necessary. Ideally, all the relevant content needed to understand Express would be part of the documentation and maintained by the community itself, which I think we are basically at that point already.

Yep, I agree with you opinion. And maybe we should go further and either ourselves or encourage others to add some of these things directly to the express site vs their blog with a link out to it. I can see a benefit of it allowing corrections over time by us and the community and the ability to section it off if it is maybe like 4x-specific or similar.

I think there are a few parts of the site that can be removed, like companies using express, and open source projects using express.

I would not disagree on that.

Other parts of the site that ask people to open a PR to have their article/project/etc included in a list could have the invitation removed, pending a decision about whether to keep those lists.

Sounds good.

@ghinks
Copy link

ghinks commented Mar 12, 2020

After the express TSC meeting last week where I volunteered to start picking up the session module triage I came to some of the same conclusions as spoken about above. There is a large list of links to compatible session stores. Although I'm sure that many of the stores are probably in a less than fully maintained state. It was very useful to have the links listed out. Without the use of at least some of them I would have had issues working out how session was working.

@jonchurch
Copy link
Member Author

jonchurch commented Mar 18, 2020

@ghinks Can you clarify for me, are you saying that the list of third party resources was essential in this case and therefore should remain as it is? Or are you saying that the list is useful, but doesn't need to be part of the Expressjs site?

I see on the session readme there is this list of 3rd party storage.

I think this is a really good point, and something we should think about.

This list, at first glance, seems difficult to maintain. Some of these projects have not been published to in 2 years or so. Yet they are certainly an important part of this package.

I'm in favor of saying that Repo Captains (assuming this gets off the ground) should be responsible for making decisions about 3rd party recommendations that directly relate to their repo. I'm happy to see them have autonomy over how to best handle this.

@ghinks
Copy link

ghinks commented Mar 18, 2020

For the session repo it was very useful. I think for testing purposes and understanding the scope and use of the module it is important. But not actually essential as I could just search to see who depends upon it.

@dougwilson
Copy link
Contributor

I would suggest separating the conversation about the express-session module into a separate issue, as the use-case is quite different than the recommendation on the expressjs.com site itself -- the background on the repo is that since it's pretty much usable without a 3rd party store, not listing them makes it quite hard to get started. Not saying this as a defense or to shut down conversation, only as a point of consideration.

@jonchurch
Copy link
Member Author

That's a good point, the recommendations come from the Readme of express-session which is imported to the expressjs site.

It's a separate but related issue to the expressjs site, specifics of express-session shouldn't be kept here.

Worth noting that some of those lists are pulled from the repos.

@dougwilson
Copy link
Contributor

You're right, I forgot that they are on expressjs.com by nature of including the docs of the various middlewares.

@jonchurch
Copy link
Member Author

jonchurch commented Apr 4, 2020

Responding to an issue started at expressjs/expressjs.com#1119 about removing the Open Source Projects Using Express Page:

Based on my original comment in this discussions thread, I personally think we should remove this page for now. (side note, there's 3 projects listed, two of which were projects belonging to the person who opened the PR to add the page) I've asked myself "what is the purpose of this page?" which seems to be "showcase open source projects using Express". As it currently stands, I don't believe we are successfully doing that.

Which leads me to another question, do we think we can succeed at meeting that purpose? Currently, I don't think we can. Perhaps in the future, we could, and I would like to see us do that. But as it stands now, I don't think that is a priority for the project.

I framed my thinking as "what is the purpose, and can we succeed in meeting that purpose" because I think that is how we should look at the site moving forward. There is a lot we can do with the site, but I'd much rather see us do the most important things to the best of our ability, and then expand from there.

Post v5 I would like to see us work on the express site, and am interested in helping to do that. I'm not too concerned with removing things currently, as there are more important things happening while v5 is being worked on.

@dougwilson
Copy link
Contributor

I whole-heartedly agree.

@crandmck
Copy link
Member

I think we can close this with landing of expressjs/expressjs.com#1484. Thanks for the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants