Characterizing alternate or conflicting points of view as assuming bad intentions without justification is both unproductive and unhealthy for the project.
> On Jul 20, 2020, at 9:14 AM, Joshua McKenzie <jmcken...@apache.org> wrote: > > This kind of back and forth isn't productive for the project so I'm not > taking this discussion further. Just want to call it out here so you or > others aren't left waiting for a reply. > > We can agree to disagree. > > On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith <bened...@apache.org> > wrote: > >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
