I don't think Benedict mentioned anything about people's motives or intentions, he simply had a concern about how marketing timelines became a factor in a release vote without the approval of the PMC. I think this is a reasonable concern, and doesn't mean that he's assuming bad intentions. That's my reading at least, although maybe I missed something?
> On Jul 20, 2020, at 7:58 AM, 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
