I don't believe there is such a thing as "lazy consensus". IMO nobody should be merging their own pull requests. And 72 hours is not enough time for feedback, especially for a major change. It is quite easy for someone to be away from work email for 72 hours with just 1 day vacation/sick time taken.
My opinion is that major changes should start in a branch, go through community review, and thorough testing. At least 2 other PMC members should review and approve the design and impact. And changes labeled as performance improvements should be accompanied by recreateable benchmarks. There are so many changes in Groovy 3 that have been slipped in, that it becomes very difficult to resist the flood; at best I can only manage to pick the 1 most disagreeable change and push back on it. Take for example the removal of the groovy-all jar. This decision was made very quickly and the build scripts no longer support the ability to create it if an org wants it. That has made it has become very difficult for transition from Groovy 2.4 to 2.5 for IDEs (aka Eclipse) and projects -- especially ones that use the "indy" flavor of groovy-all. We must not only handle the new fixes and features in 2.5 but also the new organization of artifacts -- in Groovy 2.4 we only need to manage a single artifact conflict between dependent projects. To date, our org has not switched to Groovy 2.5 because the friction has been too high trying to get away from groovy-all. I'm very concerned that Groovy 3 will present a much higher barrier to entry for existing projects.
