Hi, all. During a release vote, it can be tempting to tack on feedback about things not being voted on, but pertain to the eventual graduation of a project. For example, some glitch about content on a website. In projects with only one or few codebases, it can maybe make sense to conflate things related to a vote of one thing with anything about the project. However, I would expect that projects with a dozen repositories, that it would be easier to respond in votes only about things that pertain to what is being voted on.
If there are other things to mention, for example, rosters, web sites etc, or any other random feedback, please give that. However, I would ask to please start a new thread sent to the dev@ list if the change request would not affect the source being voted on. I would go so far as saying this is just how issues typically work. For example, ideally an issue is created on the project it relates to, and comments on an issue should relate to the issue under discussion. If you think of a release vote as an issue to close, it is possibly easier to grok why it can make sense and be easier to classify content like this. Yes, it is inconvenient for the IPMC member to start a new email thread vs tack onto the vote response, but I don't think that is much to ask. The result is less stress for the project team. In a project like Zipkin, we have a huge amount of things to do as we have like ten repos to work on. This leads to a higher level of load and stress, something we desperately desire. My 2p. -A --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
