Clarification of the unrelated content rule

[WilsontheWolf]

Recently(ish) there was a new rule added stating;

Due to the increased number of requests for js.org subdomains recently, with many having questionable relevancy to the JavaScript community and ecosystem, we've decided that going forward js.org will be focusing on accepting subdomain requests from projects with a clear relation to the JS community.

As some examples, personal pages, blogs, and Discord bot pages will no longer be accepted. Projects such as NPM packages, libraries, tools that have a clear direct relation to JavaScript, will be accepted when requesting a JS.ORG subdomain. This decision does not affect subdomains that have already been granted.

I was wondering at what point is the line crossed from related to not related.

For example, if I had a discord bot, that was written in JS and was focused on being open-source (stated it was open source and linked its GitHub on the main page) would this be considered related? Technically it's a JS tool to be used.

Now let's say we have another bot, that is oriented at helping JS developers. Mabey it included NPM search and reviews. Technically this is still a discord bot, but it's also a tool for JS developers.

Same thing with the personal pages. What if I was a JS developer and I hosted all my js projects on my page. As such this would be a personal page, but it would also be the page for JS tools.

I do understand the reasoning for this change and respect your decision. Is this looking to be a permanent change or just one to reduce the usage temporarily?

Thank you very much for hosting this service free of charge.

[MattIPv4]

Ultimately, what is accepted and was isn't falls down to the judgment of myself and Stefan when we review each request for js.org.

Personally, I will very very rarely accept a Discord bot or personal page under the new rules, as I struggle to really see the direct relevance to the JS community/ecosystem. Perhaps the one exception based on your example would be an OSS DIscord bot that has a published NPM package so that folks can use it as a framework.

@indus I'd be curious what your plans are in terms of the permanence of this rule? Personally, I see no reason to remove it, it seems to be massively helping with the random domain request spam that we got before.

[indus]

@indus I'd be curious what your plans are in terms of the permanence of this rule? Personally, I see no reason to remove it, it seems to be massively helping with the random domain request spam that we got before.

@MattIPv4 I have the same feeling. This improved our situation. One of the aspects that have improved in my oppinion is that libraries and similar content tend to be more constant with their subdomain needs. In my perception user pages, blogs etc. tend to change their names and hosting solutions more often and have a shorter half-life. Staying focused helps us to maintain JS.ORG in the long run. So I guess it is permanent.

Where the line is, is often hard to tell. Libraries and tools are the easy ones. What I find difficult is for example a page for a local JS-Meet-up. There is no need for a single line of JavaScript on the page (e.g. using Jekyll to post upcoming events). Nevertheless if someone is requesting city.js.org for that purpose I'm happy to hand it out.
I think in that case it makes totally sense (its a "org" about "js" in a "city" -> city.js.org). For libraries it is often the same. The name of the library often exactly matches the subdomain (the TLD is just a good hint that it is opensource).
User pages and blogs are not that often purely about JS but a mix of different tech stuff or hobbies of the person. So why should it be labeled as "js.org"? This often just doesn't make sense. Also just because a product uses JS I don't see a reason to label it as js.org (otherwise almost any website would qualify). I would say that JS has to be the essential and exposed! part of the webpage in question.

I don't have a fixed shema that fits all cases and ensures beeing fair to every requester. But if someone thinks we made a wrong decision there is always an option to discuss this.

If we would only support Github pages, an alternative approach could be that we blindly use the number of star ratings (with all their shortcomings). That would make decissions absolute forseeable and clear. E.g every repo with 30+ stars gets a subdomain. Hard for a personal blog - not so hard for a libary. And if a blog gets that much attention it may be worth adding.
But this would not only disqualify external hosting solutions but also hinder devs to promote a library under a certain name right from the beginning.
The percentage of JS could be another metric; but has its own problems.

I would be happy if somebody has an idea how we can really improve on this.

[MattIPv4]

Late night $0.02 via email... stars is a bad way to do it. cdnjs used to have a very strict 200 star requirement to add a library. It worked, but excluded a lot of otherwise incredibly valid and popular (on NPM etc.) packages. We expanded the rule to have criteria for GitHub stars or NPM downloads, but have since relaxed this to guidance only, not a rule, as we continued to see many valid projects being excluded by our strict need for numbers, nuance matters. Ultimately, the only way that works for deciding if a project is fit for a js.org subdomain is for a human to review it, nuance to each case is important. This is what we do currently and it seems to work well in my view. Regards, Matt Cowley Community Management, Website Design & Development, Software Engineering me@mattcowley.co.uk https://mattcowley.co.uk/

…

On 18 Feb 2021, 1:42 AM +0000, ForTombstone ***@***.***>, wrote: > E.g every repo with 30+ stars gets a subdomain. Hard for a personal blog - not so hard for a library. Makes sense, but imo people who makes good personal blogs should also be able to get more than 30+ stars. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.