Just to add, IC OS reviews take up a lot of space and often just represent noise (confirming the validity of the commit messages). I think it would make a lot more sense to mandate that reviews enclose details of this sort in…
... sections like this (expand for details)
Hello, I’m a boring detail that few people care about
The salient details that actually make an individual’s review meaningful or unique should be summarised outside of these expandible blocks.
This would significantly improve navigability of the proposal announcement thread, and avoid information overload for readers.
Thanks for the kind words @Catthew, it makes the difference I do put a lot of passion, time and effort into my write-ups.
It can be a little demotivating to see members of the grants committee go out of their way to praise an SM review for simply providing a hyperlink (while not caring to mention the highly detailed and thorough reviews left by others). I hope they’ll be more careful next month to pickup on real contributions (here’s a head start, and further discussion).
This is probably a good opportunity for me to announce that I have left CodeGov (a couple of days ago). This was due to a combination of factors, including how the grant funds are being distributed relative to time allocation (internally within CodeGov) and how other important decisions get made. I no longer feel that values of decentralisation that I hold dear are well aligned with those that are practiced by CodeGov (more context on TAGGR). That being said, I respect the team, and I’m sure CodeGov will continue to do what it does (making a positive contribution to the ecosystem).
This means I’ll no longer be conducting IC OS reviews (for CodeGov at least).
That would be nice, but I have a full-time job as a full-stack software developer which I love (IC stuff is my spare time hobby, which is fine with me)
Sorry to hear that. I could sense that your efforts were not sustainable for you. Its easy to compromise one’s values for money or tokens, at least that’s how majority of this industry works right now.
Glad to hear this. You’re going pretty hard for a hobby
Working with a corporation comes with its own downsides. Corporations prioritize profits over decentralization, almost always.
That being said I am envious of your contributions in the forum, perhaps the only one whom I envy here. I wish you the best.
so you say that proposal executions failed in the past due to missing unelection check? it would definitely make sense to include such check then.
nothing concrete, just picked a good example. there were many good examples though. just always make sure to include the proposal id in your post as @cryptoschindler outlined above. and for subnet management reviews we currently need to stick to each unique subnet thread where the proposal is posted. we cannot aggregate threads here, at least for now.
I agree it is important to improve here if we want to get more independent people and entities involved in reviewing proposals.
personally I don’t think this is really needed. but if you want you can go such route. I would recommend then to enclose the details of the whole review in one section then, possibly only the commit summary review which requires most space.
We do read, of course (thank you for fantastic in-depth analysis and comments!), and we are actively working on resolving build non-determinism. It’s a difficult problem sadly, but we’ll get there. The node team is trying to make improvements in the IC-OS build setup and this means that some problems are to be expected. The only way not to introduce problems along the way is not to make changes. And that’s probably not the best strategy
I’d love to have Mr. Lorimer on the team. However, I’m concerned that his work would lose a lot of value if he was at DFINITY. If nothing else - then because the work wouldn’t be as visible.
Totally agree with this, thanks @lorimer for your very critical and precise reviews and contributions. These are definitely read and already have resulted in a lot of improvements in the release election process and the topology optimization, and more updates will surely come!
As a formal requirement of the review? (I don’t imagine there’ll be much/any traction otherwise)
I think this is a very good suggestion. Otherwise the whole thread just becomes a big wall of words. But I do think it would be sensible to make this a formal requirement. The aim should be for the release thread to be as accessible as possible to all NNS voters. Many of these are individuals who would like to see a TLDR from each reviewer, rather than being drowned in words and scared off.
For anyone that doesn’t know, the markdown for this is as follows
<details>
<summary>Expand for a review of each commit</summary>
- Hello, I represent the review of a specific commit
- and I represent another one...
</details>
Expand for a review of each commit
Hello, I represent the review of a specific commit
and I represent another one…
Why does having a summary per commit mean there shouldn’t also be a summary for the whole proposal (which explains the main takeaways and why a reviewer voted to adopt or reject)? - basically a TLDR. I think what @cryptoschindler is suggesting is very sensible. I would add that I think this is what should sit outside of those expandable sections (while everything else, including the build hash verification screenshot, would be best collapsed by default).
I would also add that it would be sensible to ask every reviewer to provide an estimate for how long they spent on the review. This isn’t something that can be validated, but it helps ensure that expectations are aligned with reality.
This would provide valuable data for the future, when it comes to re-evaluating the original time allocation estimates put forward by DFINITY.
I will discuss this with @cryptoschindler and @lara. personally I would like to see it as we should cover all angles.
I like your proposal and totally agree. would be great if reviewers adapt this format.
this would indeed be helpful.
please note: this is a consistent learning for everybody and we will discuss and announce accordingly if we request changes to how reviews are currently handled.
The CodeGov team met on Friday and discussed the most recent requests outlined by @cryptoschindler regarding review format. We emphasized the need to follow a consistent format so it is easier on the grant review team that is checking our work. There were no concerns expressed. I don’t expect there to be any issues complying with whatever additional formatting requirements or recommendations that are announced. Please just post it in one well outlined post that we can reference. Also, please flesh out the formatting preferences over the next month if possible because we are actively working on an app where the format of all our reviews will be exactly the same. The output of the app will be a copy to clipboard that our reviewers can paste to the forum for their specific review. We are trying to automate the report creation and formatting (outline, references, summary, commit IDs, commit links, etc) as much as possible so we can focus on the technical reviews.
Hey @Jesse and @jaesharma, it occurred to me a few days ago that I owe both of you an apology, and this thread is probably the best place to put that.
You both raised valid concerns regarding grant centralisation, and I didn’t see it your way at the time, but I do now. I’m sorry for having made it harder for you to voice your concerns. It’s a wrong that I’m trying hard to right.
@cryptoschindler. The link to apply for the grant each month used to be in this Grants for Voting Neurons article, but it seems to have disappeared. Will you please provide a link now that the second month of reviews is over? Thanks!
I do put a lot of passion, time and effort into my write-ups.
That means a lot
