search

ethereumclassic / ECIPs

https://ecips.ethereumclassic.org
82 stars 61 forks source link

Fix Formatting Errors #482

Closed gitr0n1n closed 2 years ago

gitr0n1n commented 2 years ago

Fix Formatting Errors on author fields

bobsummerwill commented 2 years ago

/raw PONG _GHMoaCXLT is how the author chose to identify for two of these ECIPs, and there is no need to DOX the author with another name. Also, the name used in this PR is not a full name, either.

Best NOT to change this.

gitr0n1n commented 2 years ago

/raw PONG _GHMoaCXLT is how the author chose to identify for two of these ECIPs, and there is no need to DOX the author with another name. Also, the name used in this PR is not a full name, either.

Best NOT to change this.

This comment doesn't make much sense given this is how the Author is currently displaying. How does one DOX when its public information provided by the Author? Rhetorical question- you couldn't.

This is starting to feel like the Bob Summerwill (ETC Coop) vs Wei Tang pettiness of 2019/2020 where you submitted that string of ECIPs.

https://github.com/q9f http://ecips.ethereumclassic.org/ECIPs/ecip-1103

Regardless, I reverted to push these generally immaterial formatting changes.

gitr0n1n commented 2 years ago

Why are parenthetical identities better than bracketed?

EDIT Oh, I see, you just invented this... https://github.com/ethereumclassic/ECIPs/blame/master/_specs/ecip-1000.md#L158

Maybe we could consider some kind of syntax for specifying the app-handle relationship, like

John Doe <johndoe123@hotmail.com>
Jonh Doe (github:johndoe)

The problem is that @johndoe is ambiguous/useless for the repo as a decentralizable collection of documents, since it presumes the existence of and integration with the Github corporation.

Just fixing broken links. Absent links. Inaccurate formatting. 👍

meowsbits commented 2 years ago

Generally, editing other people signatures is going to feel wrong to me in 99% of the cases. We have no hard requirements for identitiy/entity assertion, nor should we.

Just fixing broken links.

Where are they broken? Can you please describe the issue better?

gitr0n1n commented 2 years ago

Generally, editing other people signatures is going to feel wrong to me in 99% of the cases. We have no hard requirements for identitiy/entity assertion, nor should we.

These are not "signatures". These are ECIP author headers in the Preamble. Something an ECIP editor would look at per the ECIP-1000 document. I didn't expect to rustle up your jimmies @meowsbits

gitr0n1n commented 2 years ago

Generally, editing other people signatures is going to feel wrong to me in 99% of the cases. We have no hard requirements for identitiy/entity assertion, nor should we.

Just fixing broken links.

Where are they broken? Can you please describe the issue better?

Sure. Here is an example of a broken link.

image

meowsbits commented 2 years ago

That isn't a broken link because it isn't a link. Its plain text.

gitr0n1n commented 2 years ago

That isn't a broken link because it isn't a link. Its plain text.

Here is another for you. image

meowsbits commented 2 years ago

I am OK with metadata-syntax/punctuation-only edits. But changing, adding, or removing people's names (real or claimed) is substantive, and not OK with me.

gitr0n1n commented 2 years ago

I am OK with metadata-syntax/punctuation-only edits. But changing, adding, or removing people's names (real or claimed) is substantive, and not OK with me.

Great we will start with that as I comb through this repo for generally immaterial admin clean up.

IstoraMandiri commented 2 years ago

@meowsbits

That isn't a broken link because it isn't a link. Its plain text.

In this case it looks like the author was accidentally using the wrong syntax ( instead of <, which is why the link is broken, see https://github.com/ethereumclassic/ECIPs/pull/479#issuecomment-1053909982

@gitr0n1n did not invent this, he was just adding this undocumented behavior to the docs

Maybe we could consider some kind of syntax for specifying the app-handle relationship, like (github:johndoe)

I agree, would you support overriding current (@blah) with this new (github:blah) or (twitter:blah), and while we are at it should we replace <hi@joe.com> with (email:hi@joe.com) ?

This is clearly a confusing feature currently

gitr0n1n commented 2 years ago

I agree, would you support overriding current (@blah) with this new (github:blah) or (twitter:blah), and while we are at it should we replace <hi@joe.com> with (email:hi@joe.com) ?

This is clearly a confusing feature currently

I like this formatting you are suggesting because it is clearly readable in markdown text. e.g.: (github:blah) or (twitter:blah) or (email:hi@joe.com)

cc: @ethereumclassic/ecip-editors

meowsbits commented 2 years ago

I don't opinions on the precise handle/tag syntax... Probably there are prior arts and patterns that we can reuse instead of reinventing...

Also. just by the way, ecip_validator is a gem that codifies these kinds of validations, and is currently run in the Github Actions workflow. That may be a good place for some of these kinds of validations we're talking about here.

gitr0n1n commented 2 years ago

So what's going on with this PR @ethereumclassic/ecip-editors ? We good to push and merge?