Update EIP-7329: Fix major website issue #7554
Conversation
github-actions
bot
added
c-update
File
|
|
A few thoughts here: First, I don't think SEO should be one of our major concerns, and especially not SEO optimization. Second, I think there is value in having domain-specific websites. For example, something I'd like on eips.ethereum.org that doesn't make sense for ercs.ethereum.org is to be albe to filter by fork (e.g. click a Third, re: this "Is it really worth it to you to split the website, just so you can have a marginally easier time looking at new EIPs?", I think we should be optimizing for the end users as much as we can (even if it means the "behind the scenes process is more complex"). In that case, then, yes, a "marginally easier time" is valuable. The EIPs website can slowly get optimized for what protocol contributors want, the ERCs one for what standards users want, etc. |
SEO doesn't take care of itself. Also, you haven't addressed the fact that you'll have to use anti-patterns. Quite frankly, nothing should have to "take care of itself." Why create potential problems when they can be completely avoided?
As you have said, "You could do all of this on a single website". How is this an argument against using a single website? ERCs are first-class EIPs and always have been. Also, there are plenty of non-Core non-Category EIPs that fit better with the ERCs than the Core EIPs. Your motivation for saying that You seem to be under the impression that the fact that two things have different topics and have seperate review guidelines means that they shouldn't share a domain. I think that, in this, you are mistaken. Most popular journal groups (and believe me, we are a journal transitioning to becoming a journal group at this point) do have seperate, per-topic journals (e.g. Nature has a lot). However, they all share one domain, with one search. Because that's how people work best.
I think you misunderstand here. I'm saying that the average user won't find it easier. Only a few specific people will have to avoid one button press, and the rest of us have to deal with "oh shoot, was 12582 an EIP or an ERC?". One website that can let users find everything is better than two that can't. I am open to Core-specific website changes. I think that's a great idea, and I would love Core dev feedback there! But I have yet to see an argument for having two websites from anybody. |
As I mentioned on one of the EIPIP calls the main value of website separation is that protocol development and application development are fundamentally two different audiences. Merging these two concerns onto one website blurs that distinction in an unhealthy way. There were many other arguments made on the EIPIP calls but this I think is an argument that stands on it's own. So since the explanation was spoken on a zoom call you would have heard the reason, but you would not have seen it (unless you turn close captioning on or read transcripts). |
In what way is merging the two websites unhealthy? As someone that also does research in a seperate field (Biology, of all things!), I can attest to the fact that having a single website improves UX. Think about it this way: there are a lot of Wikipedia-type projects. But when you go to get information on a subject, do you go to Wikipedia or do you go to the Wikimedia Projects page to find the domain-specific wiki? |
|
Separate websites allows each topic group to gain distinct identity, which is one of the chief positive outcomes of this migration. That way they can serve divergent needs: specifying and updating a protocol vs best practices for on-chain apps, for example. Wallet best practices and DeFi primitives could similarly be substituted. Consider a lookup of Ledger. If I want a definition (protocol) I get wiktionary https://en.wiktionary.org/wiki/ledger as a link (also, mind the case!), if I want an overview (on-chain app) I get wikipedia https://en.wikipedia.org/wiki/Ledger and if I want financial usages (DeFi) I get a more specialized entry from Investopedia - https://www.investopedia.com/terms/g/generalledger.asp All three have three different web sites and three different communities. Whether it is at the domain level of the website or at the path element is really splitting hairs: they are different websites at the end of the day. |
|
You make a fair enough point. I would be okay with Core EIPs getting their own website, as long as it's the ERCs and Interface EIPs that stay on |
|
ERCs are not called EIP ERCs, ERC-20 is just ERC-20, as is ERC-721, etc. etc. Outside of core protocol changes I've seen community members correct others saying "you mean ERC-4337, not EIP-4337." So it would be contradictory to ask people to go to eip.ethereum.org to get info on ERC-20 and to pcr.ethereum.org to get EIP-4844 info. |
|
We discussed on EIPIP 89 and decided to move forward with the website split. |
|
I can try to help if the redirects per-moved-spec is hard to implement in Jekyll |
As it currently stands, this is bad for the SEO of ERCs, and I oppose this EIP until this is fixed.
Also. You can't make 301 redirects using GitHub pages, and I will not support you using multiple anti-patterns as a workaround because of all the obvious reasons that all anti-patterns have, as well as less obvious ones like it tanks the SEO even lower.
Also. Some ERCs use relative links to EIPs, and vice versa. We should keep it that way, for SEO reasons, and because updating those might be a pain.
Finally - why do you want to split the website? I can understand the annoyance of having one repo have to share multiple different flows, but the website? Can't you just... click on the "Core" link? Is it really worth it to you to split the website, just so you can have a marginally easier time looking at new EIPs?