| 9 Dec 2021 |
 @jarrodwoodard:matrix.org | By my standards, yes.
"Seb" would be the one. | 22:00:06 |
| @jarrodwoodard:matrix.org | He's done it for several proposals.
https://www.tezosagora.org/period/61 | 22:01:13 |
| 10 Dec 2021 |
 truey | Especially period 48. In my view they’re more an eyesore than time-suck. I don’t think increasing proposal complexity and friction to good actors is worth the trade-off, not to mention circumventing the proposal mitigation system is fairly easy for a bad actor with enough wealth (voting power) assuming a forfeiture threshold is not set to a level that disincentives good actors from participating. | 06:23:53 |
| @jarrodwoodard:matrix.org | Fair points but ostensibly someone with more skin in the game is less likely to behave so frivolously.
Also, it's not meant to be a perfect system. Just to mitigate the low-hanging fruit.
I am not seeing much added complexity and friction for good actors. Could you break that down for me? | 06:56:38 |
| truey | See my comments in brackets within a snippet of your tzip draft:
“This would be achieved by requiring a bond to be included along with the proposal [increased system complexity and participant friction]. Should the proposal not reach a minimul, pre-defined percentage of votes, the bond would be forfiet [increased system complexity and participant friction]. The bond should be burned for the time being [increased system complexity and participant friction]. In the future it could perhaps be added to an on-chain treasury [increased system complexity].”
Implementation of 👆 requires allocation of limited developer resources; not of insignificant importance. | 16:18:59 |
| 11 Dec 2021 |
| @jarrodwoodard:matrix.org | For point 1 - I don't think it adds any friction for the user. Their experience is unchanged, they either vote yay nay or pass or completely ignore the proposal. | 17:51:59 |
| @jarrodwoodard:matrix.org | You're absolutely right to point out the increased system complexity and the need for dev time.
That should certainly be weighed and considered and this proposal should fall behind many far more important improvements.
The way to get this Improvement included ( should it be a benefit ) while using our resources economically. Is to go slow, think things through and not being a rush.
The process has to begin somewhere so and the sooner the better. | 17:54:25 |
| @jarrodwoodard:matrix.org | * You're absolutely right to point out the increased system complexity and the need for dev time.
That should certainly be weighed and considered and this proposal should fall behind many far more important improvements.
The way to get this Improvement included ( should it be a benefit ) while using our resources economically. Is to go slow, think things through and not be in a rush.
The process has to begin somewhere so and the sooner the better. | 17:55:15 |
| @jarrodwoodard:matrix.org | * You're absolutely right to point out the increased system complexity and the need for dev time.
That should certainly be weighed and considered and this proposal should fall behind many far more important improvements.
The way to get this Improvement included ( should it be a benefit ) while using our resources economically. Is to go slow, think things through and not be in a rush.
The process has to begin somewhere though and the sooner the better. | 17:55:27 |
| truey |
-
User wealth risk -> more user friction
-
Increased system complexity -> use of limited developer resources
-
-
- is not currently worth at best a reduction of a superficial proposal eyesore and at worst a system malfunction and good actor proposal participation reduction.
May I recommend focusing on system/UX simplification suggestions? | 18:43:40 |
| truey | *
- User wealth risk -> more user friction
- Increased system complexity -> use of limited developer resources
1 + 2 is not currently worth at best a reduction of a superficial proposal eyesore and at worst a system malfunction and good actor proposal participation reduction.
May I recommend focusing on system/UX simplification suggestions? | 18:44:04 |
| @jarrodwoodard:matrix.org | Fair on point 1, I overlooked the wealth risk. It's a bit of more friction but worth it imo.
Regarding the developer resources and added complexity. I agree it is not worth prioritizing right now.
I don't see this causing any good actor to not participate.
Something like this will imo inevitably be necessary. It is an oversight, where value can be extracted without much cost. Bad actors will take advantage of it.
For example, assuming a proposal name exists onchain forever and can be custom set ( I could be wrong here )... how long until it is used for obscenities or as storage.
Again, I'm not looking to rush a solution. There are bigger fish to fry, and the longer this is touched on from time to time as a low priority but necessary upgrade, the lower the end cost in dev time at least, and perhaps complexity as well. | 18:54:08 |
| 16 Dec 2021 |
| @jarrodwoodard:matrix.org | Made some updates to the TZIP to better protect against good actors getting accidently penalized.
| 00:16:12 |
| 19 Dec 2021 |
| @jarrodwoodard:matrix.org | I plan on doing a PR for TZIP 25 to the main repo.
I'm kind of a git noob, so there may be a bit of trial and error. | 18:59:54 |
| 27 Dec 2021 |
|  fredcy changed their profile picture. | 17:27:15 |
| 2 Jan 2022 |
|  realcoredump joined the room. | 01:37:17 |
|  ForsetiT changed their profile picture. | 13:07:13 |
| 5 Jan 2022 |
|  decentralgabe joined the room. | 06:38:34 |
| decentralgabe changed their display name from glcohen to decentralgabe. | 06:39:44 |
| 7 Jan 2022 |
|  Nicolas O | MIDL.dev joined the room. | 23:12:26 |
| 8 Jan 2022 |
|  klick.tez joined the room. | 02:58:04 |
| 9 Jan 2022 |
|  @rafoo:matrix.org joined the room. | 20:12:09 |
|  Kevin Mehrabi | kevin.tez changed their profile picture. | 22:25:28 |
| 12 Jan 2022 |
| Kevin Mehrabi | kevin.tez | https://twitter.com/KMehrabi/status/1479557124724170754 | 01:51:56 |
| truey | Upon discovery of a critical Tezos code failure, what is the maximum limit the on-chain governance system will theoretical ‘block’ developers from a code fix assuming a unanimous at quorum vote to immediately implement a code update exists? | 03:04:11 |
| decentralgabe | Arthur has spoken that in these cases a hard fork is essential to bypass the governance process and secure the network | 03:05:05 |
| truey | Has anyone suggested governance process alternatives that would keep such critical time-sensitive use cases on-chain? | 03:09:04 |
| decentralgabe | I suppose a bypass vote could work, but in practice may be too slow. You’d need a barebones method to signal “this is critical, this is the fix, upgrade now” | 03:10:24 |
| 16 Jan 2022 |
|  niki joined the room. | 22:14:57 |
| 17 Jan 2022 |
|  DegenLA joined the room. | 16:48:19 |
