Dave, I am not saying that we should make the decision solely based on organization votes. This is just an extra input we can use while making the decision.
By looking at the threads, looks like we don't have a community consensus here. Then the question is: how do we make a *better* decision without a community consensus. I would like get inputs from organization's perspective because I believe the order of complexities of changing the internal config/monitoring stack within organizations are the same regardless of their sizes. So gathering inputs from that perspective should be helpful for us to make a better decision. - Jie On Wed, Jun 3, 2015 at 8:57 AM, Dave Lester <d...@davelester.org> wrote: > Hi Jie, > > I understand your concern here, but within Apache projects, > "organizations" do not have a voice/vote -- people do. > > I think should take into strong consideration the overhead any change > may have on any adopter/organization and discuss those risks and > problems openly, but ideally this decision would be made based upon > consensus within the community. If consensus cannot be reached, a vote > among committers may be necessary. > > Dave > > On Wed, Jun 3, 2015, at 08:52 AM, Jie Yu wrote: > > Adam, > > > > If a vote is called out, how do we decide if it passes or not. Will that > > be > > the same of voting for a release (i.e., PMC member can veto it)? > > > > I would imagine that some PMC members might want to express some negative > > feedbacks on this, but certainly do not want to veto it. How do we deal > > with this situation? > > > > As already pointed out in the thread, this name change requires large > > amount of work on changing the internal config files, monitoring stack > > and > > a complicated rolling out procedure. > > > > Because of that, I would like to propose that we also *count votes by > > organization* and take that into account. We probably don't want to pass > > a > > vote if a majority of the organizations do not want it, right? We'll > > decide > > each organization's +1/-1 by looking at votes from their employees (e.g., > > by majority). > > > > If one does not have an organization associated with, his/her vote will > > be > > put into a separate pool. If an organization wants to stay anonymous, > > just > > use a label (but make sure to use the same label if there are multiple > > votes from the same organization). > > > > How does that sound? > > > > - Jie > > > > > > > > On Mon, Jun 1, 2015 at 2:18 PM, Adam Bordelon <a...@mesosphere.io> > wrote: > > > > > There has been much discussion about finding a less offensive name than > > > "Slave", and many of these thoughts have been captured in > > > https://issues.apache.org/jira/browse/MESOS-1478 > > > > > > I would like to open up the discussion on this topic for one week, and > if > > > we cannot arrive at a lazy consensus, I will draft a proposal from the > > > discussion and call for a VOTE. > > > Here are the questions I would like us to answer: > > > 1. What should we call the "Mesos Slave" node/host/machine? > > > 2. What should we call the "mesos-slave" process (could be the same)? > > > 3. Do we need to rename Mesos Master too? > > > > > > Another topic worth discussing is the deprecation process, but we don't > > > necessarily need to decide on that at the same time as deciding the new > > > name(s). > > > 4. How will we phase in the new name and phase out the old name? > > > > > > Please voice your thoughts and opinions below. > > > > > > Thanks! > > > -Adam- > > > > > > P.S. My personal thoughts: > > > 1. Mesos Worker [Node] > > > 2. Mesos Worker or Agent > > > 3. No > > > 4. Carefully > > > >
