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 > >
