request: please keep feedback categorized to what's being voted on

[Adrian Cole <ad...@gmail.com>]

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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org