He highlighted that developers have seven options to express their stance on a proposal, with only two options indicating community support. These options allow developers to acknowledge a proposal as 'prefer' or 'acceptable', or to reject it with 'no'. Modifications have been made to three categories to refine their definitions, including removing the association of community support from the 'no' option and rephrasing 'prefer' and 'evaluating'.

Kogman also addressed the concerns about the potential impact of eliminating some categories, emphasizing the importance of maintaining the integrity of the existing system to avoid disruptions. He acknowledged the diverse perspectives within the Bitcoin developer community and advocated for allowing individuals the freedom to express their views, even if they choose to label a proposal as 'deficient' or 'wanting'. This approach underscores the value placed on diverse input and the desire to accommodate varying degrees of caution and scrutiny among contributors.

Furthermore, Kogman announced the upcoming addition of a feature that will enable contributors to include links to their rationale behind opinions on opcodes, enhancing transparency and understanding within the community. This update was previously mentioned on social media but had not been communicated through the mailing list. In addition to these procedural updates, Kogman has facilitated the inclusion of links to Bitcoin Improvement Proposal (BIP) drafts for all opcodes, ensuring that detailed information is accessible for thorough evaluation and discussion. This effort demonstrates a commitment to fostering informed participation and comprehensive review processes within the Bitcoin development ecosystem.