EIPIP Meeting 16 Agenda

[poojaranjan]

Date and Time

Wednesday, Sep 09, 2020, at 15:00 UTC

Location

Zoom: The link will be shared in the telegram group.
YouTube Live Stream/Recording

Agenda

1. Network upgrade repository and process

2. Relative vs Absolute Paths

3. Further discussion on EIP working groups

4. EIP triaging permissions

5. Onboarding EIP editors survey to set expectations of an EIP Editor

6. Clarifications for how a precompile address is decided.

7. Review action items from previous meeting

Next Call - Sep 23, 2020.

[MicahZoltu]

Agenda Item: Relative vs Absolute Paths

[EIP-1](./eip-1.md)

vs

[EIP-1](https://eips.ethereum.org/EIPS/eip-1)

Relative Pros

• If you create a fork of the repository, the links will link to files in your fork (which matters when you are referring to assets, other EIPs that may be created in your fork, etc.)
• If you create a mirror of the EIPs website, the links will keep you on your mirror.
• If you browse the EIPs website via IPFS or swarm, the links will keep you on IPFS/swarm.
• If you are browsing the EIPs repository via GitHub, the links will keep you on GitHub.
• If you create a localization of the EIPs website, the links will keep you on your localized site.

Absolute Pros

• If a user accidentally ends up on a GitHub version of the EIPs site and then they click a link, they'll be redirected back to the official EIPs website.
• (maybe other benefits I'm not aware of)

Current Strategy

Currently, there is a mix of absolute and relative paths since it was not clearly documented anywhere that there is a well defined style, so different editors have been pushing for different paths. There was a series of pull requests a while back that mass updated links a while back, but many EIPs have been created and merged since then so it is no longer consistent across the repository.

EIP-1 uses [EIP-1] for links internally, which actually causes everything to redirect to GitHub (arguably the absolute most wrong way to do it). EIP-1 explicitly states that assets should be referenced using relative links. EIP-1 does not explicitly state how EIPs should be linked within EIPs.

Prior Discussion

ethereum/EIPs#1733 (comment)
ethereum/EIPs#1730
(maybe more that I have been unable to track down)

Personal Opinion

I'm pretty strongly against absolute links and in favor of relative links. Relative links being "correct" is reasonably well established in the web because it means your site continues to work if it moves, gets rearranged, goes through a rebranding, is mirrored, in development environments, staging environments, localized environments, etc. We already have 2 ways of viewing EIPs (github.com and ethereum.org), and at the moment internal links in one redirect you to the other.

I find the argument that users will find their way back to ethereum.org if they accidentally end up on some old GitHub to be a bit weak. It requires the user first end up on GitHub via some mechanism, and then it requires that they naturally browse to some other EIP via the EIP they are viewing. The set of people who end up on some old version of the site accidentally is pretty rare, and then odds that someone who accidentally ended up there then follows a link and gets redirected is very small. All in all, I think the number of people protected by this mechanism is incredibly small since very few people browse EIPs, and those who do are usually experienced EIP editors and core devs, rather than random people on the internet that don't realize eips.ethereum.org exists.

It is possible there is more discussion than what I was able to find, but the discussion I did find appears to have only two people involved (who disagreed). Without finding evidence of additional discussion, I'm hesitant to say that there was consensus on the issue previously. Making changes without requiring full consensus is fine by me (better to iterate and get it wrong than stagnate), but I just am uncomfortable to use "we already discussed this" as an argument that we shouldn't discuss the topic again.

I DO think that we should be consistent throughout the repository. If we decide to switch to relative paths I will volunteer to do a mass change of all existing links. If we decide to go with absolute paths, I will follow the group going forward with new EIPs and use absolute paths.

[lightclient]

I also believe that relative links are the way to go. It give much more flexibility in terms of rendering the resulting site.

With that said, I don't know how this group can make a decision on this. You and @Souptacular are generally the only editors in here. I think it would be helpful to have a better "guiding philosophy" for the EIPs repo. This could be used to answer questions like this. My opinion is that the repo should not cater to end-user viewing and therefore we should not make any optimizations for them (e.g. redirecting them to the "source of truth" if they end up on a weird branch).

[lightclient]

I have no updates on the working groups at this time. Although I would like to eventually have this structure, I think the "break out" session this week was really effective and, for the time being, a reasonable solution.

[poojaranjan]

Closing in favor of #33