Require that discussions-to points to Ethereum Magicians
#43
Comments
|
I don't think Ethereum Magicians should be a requirement? It can't be the issue itself, but there's no requirement that it be any one forum. |
|
The latest agreement among editors (after many months of discussion) is that all discussion links should be on Ethereum Magicians. The primary argument is that you can login to Ethereum Magicians via GitHub account with minimal permissions, so there isn't any reason someone wouldn't be able to post there and it keeps discussion in one cohesive place. There is an outstanding issue to remove the edit timer on Ethereum Magicians, and we should get that fixed prior to implementing this. |
|
You can also log on to a variety of other forums via GitHub, including GitHub issues. This proliferation of unwritten rules is making the EIP process needlessly bureaucratic and difficult to navigate. Why aren't these proposed as amendments to EIP 1, at least? |
Because we are woefully understaffed and things often don't make it to EIP-1 like they should. Pull requests very welcome!
This doesn't solve the problem of consistency across EIPs and simplicity of implementation (editors don't need to make judgement calls on what discussions-to locations are appropriate).
We are wanting to use GitHub issues for tracking EIP process changes/improvements/suggestions. This is easier/simpler when the issues are full of discussion links for various EIPs. |
I'm not sure how I could do this, since these rules seem to only exist in the heads of a few EIP editors. How much editor time is wasted explaining these unwritten rules to people when they unwittingly violate them?
Why is it important that all EIPs have their discussions in the same place? Are you dealing with a lot of users trying to use forums other than Ethereum Magicians? If so, doesn't that tend to indicate they're not being well served by the current system? If not, what purpose does this new rule serve? One example I would love to see become a best-practice that this rule prohibits is linking to an issue tracker as the discussions-to URL; this permits actually tracking individual queries and proposed changes and closing them out when they're implemented, which reduces the probability of feedback being accidentally forgotten and should lead to more robust EIPs.
I assume you meant to say this is easier/simpler when the issues are not full of discussion links. Isn't this what tags are for, though? You could also use a separate repo for meta-discussion. |
|
TL;DR: The best way to get better rules is to figure out how to get more active editors. Understaffing is an underlying motivation behind many rules we have.
I just meant you are welcome to create a PR to update EIP-1 with this rule. 😄
Much! We definitely should get better at updating EIP-1 with new rules. It is one of the tasks that often falls by the wayside when understaffed though. The underlying theme behind a lot of the recent rule changes is that we are woefully understaffed. One of the major driving forces behind most rules we create is reducing editor workload. In the case of discussions-to, editors having one less thing they have to review decreases editor workload. The way to remove this work is by having automated checks against it. To achieve this, we have 2 options:
We could achieve this motivating goal with (1), but it results in people putting discussion-to links all over the place like Twitter, Reddit, Pull Requests, etc. (2) on the other hand gives us a very easy to implement automated check that reduces editor workload while maintaining some level of consistency and quality in EIPs. One could argue, "well, you can allow Ethereum Magicians + GitHub Issues" or "Ethereum Magicians + X, Y, and Z", but now we need to maintain a labeling system on the issues which is "more work" and deal with debates around which discussion targets should be allowed and which shouldn't. All of these things are individually small, but they add up to a non-trivial amount of work. Also, I do think there are benefits to consolidating discussion in a consistent place, though I can appreciate that those benefits are marginal. If we had more people working on the EIP Editing process there would be a whole lot more good options available to us like maintaining a whitelist, individually gauging and curating each discussions-to location, doing much more complicated/fancy things with issue tracking systems, etc. As soon as we have ample people regularly doing EIP Editing I would become much more open to all of these options. At the moment though, we have a skeleton crew and every little bit of automation we can add (without huge amounts of engineering effort) is another step toward having an EIP process that is functional and away from a process that is completely defunct (like it was for a year or two a while back, where people's EIPs would sit for over a year awaiting editor review). |
|
At the risk of derailing this discussion, ideally I'd like to see |
|
@SamWilsn Does Discourse not have a system in place for backups? Or is your concern that those backups are not in some open/portable format? |
|
Discourse is fine too! Are there publicly available backups for the Ethereum Magicians instance, and scripts to restore it? |
|
This is an excellent question for the Ethereum operations team. @poojaranjan do you know who we bring into this conversation who would know? |
|
I think you're looking for another Pooja (Pooja Ranjan)
…On Sun, Feb 27 2022 at 23:38, Micah Zoltu < ***@***.*** > wrote:
This is an excellent question for the Ethereum operations team. @pooja (
https://github.com/pooja ) do you know who we bring into this conversation
who would know?
—
Reply to this email directly, view it on GitHub (
#43 (comment) ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/ABLH2S4OETL2D4U6GLH67JTU5L32TANCNFSM5M3L66ZQ
).
Triage notifications on the go with GitHub Mobile for iOS (
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
) or Android (
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
).
You are receiving this because you were mentioned. Message ID: <ethereum/eipv/issues/43/1053880982
@ github. com>
|
|
I hope the editing timer issue can be looked into by the FEM team. Adding @jpitts to weigh in! |
Yes, sorry! I edited my comment immediately after submitting, I was hoping an email notification wouldn't go out but alas, I was not quick enough. 😢 |
Last I checked, Discourse supports manual S3 backups with a provided frequency For automated backups, I found this bash script picked from discussion here @jpitts thoughts? |
As opposed to a GitHub issue or back to the PR itself.
The text was updated successfully, but these errors were encountered: