Firstly, that is a very strong claim that in this particular case is disputed 
by the facts.  You made a very specific claim that the delay was "risking our 
currently lined up coordination with journalists and other channels". I am not 
the only person to interpret this as implying coordination with journalists, 
contingent on a release schedule not agreed by the PMC.  This was based on 
semantics only; as far as I can tell, no intentions or assumptions have entered 
into this debate, except on your part.

> Which is the definition of not assuming positive intent.

Secondly, this is not the definition of positive intent.  Positive intent only 
indicates that you "mean well"

Thirdly, in many recent disputes about governance, you have made a negative 
claim about my behaviour, or ascribed negative connotations to statements I 
have made; this is a very thinly veiled example, as I am clearly the object of 
this criticism.  I think it has reached a point where I can perhaps 
legitimately claim that you are not assuming positive intent?

> motives, incentives ... little to do with reality

It feels like we should return to this earlier discussion, since you appear to 
feel it is incomplete?  At the very least you seem to have taken the wrong 
message from my statements, and it is perhaps negatively colouring our present 
interactions.


On 20/07/2020, 15:59, "Joshua McKenzie" <jmcken...@apache.org> wrote:

    >
    > If you are criticised, it is often because of the action you took;

    Actually, in this case and many others it's because of people's unfounded
    assumptions about motives, incentives, and actions taken and has little to
    do with reality. Which is the definition of not assuming positive intent.

    On Mon, Jul 20, 2020 at 10:41 AM Benedict Elliott Smith 
<bened...@apache.org>
    wrote:

    > Thanks Sally, really appreciate your insight.
    >
    > To respond to the community discourse around this:
    >
    > > Keep your announcement plans ... private: limit discussions to the PMC
    >
    > This is all that I was asking and expecting: if somebody is making
    > commitments on behalf of the community (such as that a release can be
    > expected on day X), this should be coordinated with the PMC.  While it
    > seems to transpire that no such commitments were made, had they been made
    > without the knowledge of the PMC this would in my view be problematic.
    > This is not at all like development work, as has been alleged, since that
    > only takes effect after public agreement by the community.
    >
    > IMO, in general, public engagements should be run past the PMC as a final
    > pre-flight check regardless of any commitment being made, as the PMC 
should
    > have visibility into these activities and have the opportunity to 
influence
    > them.
    >
    > > There has been nothing about this internally at DS
    >
    > I would ask that you refrain from making such claims, unless you can be
    > certain that you would have been privy to all such internal discussions.
    >
    > > there's really no reason not to assume best intentions here
    >
    > This is a recurring taking point, that I wish we would retire except where
    > a clear assumption of bad faith has been made.  If you are criticised, it
    > is often because of the action you took; any intention you had may be
    > irrelevant to the criticism.  In this case, when you act on behalf of the
    > community, your intentions are insufficient: you must have the community's
    > authority to act.
    >
    >
    > On 20/07/2020, 14:00, "Sally Khudairi" <s...@apache.org> wrote:
    >
    >     Hello everyone --Mick pinged me about this; I wanted to respond
    > on-list for efficacy.
    >
    >     We've had dozens of companies successfully help Apache Projects and
    > their communities help spread the word on their projects with their PR and
    > marketing teams. Here are some best practices:
    >
    >     1) Timing. Ensure that the Project has announced the project milestone
    > first to their lists as well as announce@ before any media coverage takes
    > place. If you're planning to time the announcements to take place in
    > tandem, be careful with embargoes, as not everyone is able to honor them.
    > We've been burned in the past with this.
    >
    >     2) Messaging. Keep your announcement plans and draft press releases,
    > etc., private: limit discussions to the PMC. Drafting announcements on
    > public lists, such as user@, whilst inclusive, may inadvertently expose
    > your news prematurely to the press, bloggers, and others before its ready.
    > This can be detrimental to having your news scooped before you actually
    > announce it, or conversely, having the news come out and nobody is
    > interested in covering it as it's been leaking for a while. We've also 
been
    > burned in the past with this. Synching messaging is also helpful to ensure
    > that the PMC speaks with a unified voice: the worst thing that can happen
    > is having someone say one thing in the media and another member of the PMC
    > saying something else, even if it's their personal opinion. Fragmentation
    > helps no-one. This recently happened with a Project on a rather
    > controversial topic, so the press was excited to see dissent within the
    > community as it gave them more to report about. Keep things co
    >      ol: don't be the feature cover of a gossip tabloid.
    >
    >     3) Positioning. It's critical that whomever is speaking on behalf of
    > the Project identify themselves as such. This means that the PMC needs to
    > have a few spokespeople lined up in case of any media queries, and that 
the
    > spokespeople supporting the project are from different organizations so 
you
    > can . I cannot stress enough the need to exhibit diversity, even if
    > everyone working on the media/marketing side is from a single organization
    > --the ASF comes down hard on companies that "own" projects: we take
    > vendor-neutrality very seriously. What's worked well with organizations
    > that have pitched the press on behalf of a project is to pitch the project
    > news, have spokespeople from other organizations speak on behalf of the 
PMC
    > and follow up with different spokespeople/companies that have supporting
    > products or activities. The ability to showcase breadth of deployment
    > demonstrates Project relevance.
    >
    >     There have been instances of companies pre-announcing Project news and
    > milestones before the Project has done so themselves, in the form of press
    > releases, blog posts, articles on Medium/DZone/elsewhere, or on social
    > media. Whilst we appreciate their enthusiasm, it has caused significant
    > erosion of goodwill within the community, and issues with the press.
    >
    >     Apache Projects that have been successful with outside (corporate)
    > support to help with marketing and media relations have shared their press
    > announcements, articles, posts, and pitches prior to going live to ensure
    > that they are balanced and have proper attribution and form. I'm happy to
    > help with this if needed.
    >
    >     Briefing analysts is a bit of a different situation, and I'm happy to
    > help with that as well.
    >
    >     Best of luck,
    >     Sally
    >
    >     + forwarding to press@ as well to keep everyone in the loop
    >
    >     - - -
    >     Vice President Marketing & Publicity
    >     Vice President Sponsor Relations
    >     The Apache Software Foundation
    >
    >     Tel +1 617 921 8656 | s...@apache.org
    >
    >     On 2020/07/20 09:44:31, "Mick Semb Wever" <m...@apache.org> wrote:
    >     >
    >     > > Our plan is to share the community-approved blog with reporters
    > who have
    >     > > expressed interest in Cassandra, which may result in coverage. We
    > also
    >     > > developed a 4.0 beta graphic that anyone is welcome to use.
    >     > >
    >     > > FWIW our timeline revolves around yours. We're ready to reach out
    > just as
    >     > > soon as the beta is cut; no need to adjust anything on our behalf.
    > If
    >     > > you're available for emailed or live interviews, please shoot me a
    > note.
    >     > >
    >     > > We're here to help C*. I've spoken with a handful of folks already
    > about
    >     > > how to best achieve that, and the door is open - reach out 
anytime!
    >     >
    >     >
    >     > Thanks Melissa! If all goes well there should be a 4.0 beta release
    > ready for public this week.
    >     >
    >     > Coordinating media releases around open source releases is not
    > something I've seen much of, or have much experience with. I can imagine
    > that it is always going to be clumsy around an organic group of 
individuals
    > around the world, individuals doing their best to be independent from the
    > companies that employ them, companies that each have own stake in the
    > project. We just have to do our best! If people know of other OSS projects
    > doing this well it would be great to know and learn from them.
    >     >
    >     > To all non DataStax folk, I've only seen Melissa's work in this
    > community (dev and private ML). There has been nothing about this
    > internally at DS. The only thing I've heard about the media coordination 
is
    > from Josh's post here, and I made mention of it when raising the vote:
    > 
https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E
    >     >
    >     > DS of course benefits from a successful OSS project, but so do we
    > all, so do please help Melissa (and all new contributors) out, there's
    > really no reason not to assume best intentions here.
    >     >
    >     > regards,
    >     > Mick
    >     >
    >     > 
---------------------------------------------------------------------
    >     > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
    >     > For additional commands, e-mail: dev-h...@cassandra.apache.org
    >     >
    >     >
    >
    >     ---------------------------------------------------------------------
    >     To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
    >     For additional commands, e-mail: dev-h...@cassandra.apache.org
    >
    >
    >
    >
    > ---------------------------------------------------------------------
    > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
    > For additional commands, e-mail: dev-h...@cassandra.apache.org
    >
    >



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Reply via email to