Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 02 2018 09:26
    @Arachnid banned @johnny_musk_twitter
  • Jun 06 2018 10:22
    @Arachnid banned @ethsupport1
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
  • Jun 05 2016 10:37
    @chriseth banned @adamskee
Nick Johnson
@Arachnid
@MicahZoltu Virgil Griffith. Feel free to ping him about the idea. :)
Alex Beregszaszi
@axic

Since eips.ethereum.org doesn’t have linking to headings, here’s a github link: https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md#eip-work-flow

Scroll down to "Work in progress (WIP)” and check out the entire paragaph.

Nick Johnson
@Arachnid
@axic But we were discussing that line you quoted, no?
Alex Beregszaszi
@axic
That is the first line of the entire block I have also paste a screenshot of.
Nick Johnson
@Arachnid
I'm not saying it's not. But previously you were saying that line constituted a requirement.
All I was arguing is that it doesn't, because it doesn't state anything about how the draft should look.
Oh, and if you hover over the heading, and click on the link icon, it will generate you a link to that header.
Alex Beregszaszi
@axic
I kind of think arguing to this extent is not helping. If you scroll up, I have stated multiple times that I’m looking at the entire section and not a single line in isolation.
I really need to move on to other tasks. My closing comment: EIP-1 is vague.

Oh, and if you hover over the heading, and click on the link icon, it will generate you a link to that header.

Hovering over “EIP Work Flow” doesn’t do anything on Firefox.

Nick Johnson
@Arachnid
Weird, it works in Chrome.
Micah Zoltu
@MicahZoltu
Not in Chrome either.
Nick Johnson
@Arachnid
It works for me in my copy of Chrome.
Micah Zoltu
@MicahZoltu
You may be thinking of viewing EIP-1 in GitHub rather than the rendered one on eips.ethereum.org?
Nick Johnson
@Arachnid
Nope. Though I can't seem to reproduce it now.
Micah Zoltu
@MicahZoltu
GitHub's markdown renderer generates the anchor links for headings. I don't think Jeckyll (or whatever is being used) does.
Nick Johnson
@Arachnid
Actually, you're right. I must have ended up there somehow without noticing.
James Hancock
@MadeofTin

Well, I have been away from the internet and missed a lot here. I will share my thoughts in brief.

For the community members who don't regularly use Github any EIP that is not on http://eips.ethereum.org/ doesn't exist. They don't understand what a pull request means and that technically being a PR or merged as Draft are not different. Pointing them to a PR that requires a lot of background knowledge about Github and general CS is more than confusing, it is a barrier to entry.

On #2025 I have requested comments multiple times on this channel and have received none. A lack of comments shows a lack of opposition to being merged. If I have to wait for someone to make a comment I may have to wait for ever.

What does it mean to be technically sound. The idea of Block Rewards is technically sound. I am not sure what is confusing about the specification. Either way rather than debate what it means to be Technically sound or not, I suggest we remove that language from EIP-1.

James Hancock
@MadeofTin
#2147 Here is a PR
for the change
Any other suggestions for removal and I am happy to make a PR for it.
James Hancock
@MadeofTin
Removing the language bit by bit that is the friction between Editors overtime hopefully smooths the process out for everyone.
James Hancock
@MadeofTin
There is a lot on the plate of Editors and I hesitate pinging any of you as you already are doing so much. So, as an author I don't know what is the best course of action when progress stalls on an EIP I work on. What are your suggestions for us?
Greg Colvin
@gcolvin

100 messages since yesterday, so my opinions are based on a quick skim, sorry.

@Arachnid says, "Virgil is working on an alternate EIP process that brings in an external standards company to manage the process.”

This sounds like a terrible idea, unless the outsider is little but a clerk. But then I can’t see needing a whole company. I believe Hudson the @Souptacular is on salary, and overloaded with responsibilities. Perhaps the EF can hire him an asstiant?

@MadeofTin says, "For the community members who don't regularly use Github any EIP that is not on http://eips.ethereum.org/ doesn't exist."

Yes, this is pain. https://github.com/ethereum/EIPs/issues can be a good place for proposals that are ready to discuss, (at the author's option) but not to write up in the full form of a draft. The number that is assigned is from the same series as the PR numbers, so can serve as the EIP number, and stay the same if a PR is made. Discussions can be sent to the Magicians if desired. And Github now maintains a history of edits to the issue. So a working copy of a proposal can be maintained with simple source control, and a simple editor. And abandoned proposals only clutter the Issue space, not the PR space.

And I thought we agreed long ago, and reaffirmed after the lost funds hassle, that Draft PRs only needed to meet the form of a PR. Thus the auto-merger. And I don’t think we should require an implementation to get to Final, though in Last Call it might be called out as needed for a particular PR.

And all this may be irrelevant if I’ve misunderstood. And now I need to get back to earning a living. I’ll check in later. Thanks.

Alex Beregszaszi
@axic
This https://github.com/ethereum/EIPs/pull/2051#issuecomment-506520137 has sparked an idea to create some graphs for status changes.
Screenshot 2019-06-27 at 22.42.04.png
Here’s the first attempt, which made me realise I’d need to create 2 different graphs to keep it clearer:
  • EIPs
  • ERCs
This is what it looks like if I try to include everything happening today:
Screenshot 2019-06-27 at 22.44.59.png
Nick Savers
@nicksavers
Ah the visualization helps
The Rejected status seems to make it a lot more complicated. And I don't see what happens after Deferred.
Alex Beregszaszi
@axic
Right, deferred would move back to accepted for the next hard fork. In general I don’t like deferred.
Nick Savers
@nicksavers
I also think that Abandoned proposals should get another chance after the author decides to revive it.
Alex Beregszaszi
@axic
Screenshot 2019-06-27 at 23.19.07.png
Nick Savers
@nicksavers
I agree Deferred is not really useful
Alex Beregszaszi
@axic

Also likely there should be a path from “Accepted” to “Draft”. That’s why accepted is a bad name.

ERCs move from Last Call to Final, but EIPs move from Last Call to Accepted and can still change after the Accepted state.

Nick Savers
@nicksavers
Hmm that I don't understand
Alex Beregszaszi
@axic
Or perhaps it is enough saying that changes can be made to “Accepted” EIPs? But then what is the point of Accepted. A bit confusing to be honest.
Nick Savers
@nicksavers
I think the only reason for Accepted was to motivate client devs to start implementing before the next fork.
Alex Beregszaszi
@axic
That is now listed on the hard fork meta EIPs.
Maybe a better name would be “Stable” or “Reviewed” ?
Danno Ferrin
@shemnon
I would say progpow is in the deferred state. I think the state is useful.
Alex Beregszaszi
@axic
It is in the “Draft” state according to eips.ethereum.org
Danno Ferrin
@shemnon
Yea, after the january “accepted” call the state never got updated. It also never went through last call, like most hard fork EIPs. We’ll get better about that, right?
Alex Beregszaszi
@axic
I think it is unlikely to get better when we have this convoluted system with plenty of undocumented exceptions, undocumented rules and unenforced rules :wink:
Greg Colvin
@gcolvin
:(
Alex Beregszaszi
@axic
@makoto @arachnid we need these two merged to use the new field/statuses: makoto/eip_validator#3 and makoto/eip_validator#4
James Hancock
@MadeofTin
  • to changing the verb for "accepted" Trying to explain to someone what makes it into istanbul and what doesn't is difficult Because being accepted into istanbul doesn't mean it has reached the status "accepted". So it is accepted but not Accepted. Nearly every time I have to explain the nuance between the language to an already complicated process
Stable -> Live instead of Accepted -> Final
Live referencing it has been implemented into the main chain
Or, "Approved" instead of Accepted. Referencing that the EIP has been Approved by the coredevs for client implementation
James Hancock
@MadeofTin
'+ 1 to changing the verb for "accepted"'*