sorry, my phone got unlocked accidentally in my pocket. please ignore the empty email.
On Tue, 21 Jul 2020 at 18:40, Jasonstack Zhao Yang < jasonstack.z...@gmail.com> wrote: > > Blake Eggleston <beggles...@apple.com.invalid> 于 2020年7月21日周二 01:57写道： > >> 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 >> >>
