Update charter with communication responsibilities #1754
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -74,9 +74,24 @@ including: | |||||
| * Development process and any coding standards. | ||||||
| * Mediating technical conflicts between Collaborators or Foundation | ||||||
| projects. | ||||||
| * Establishing and stewarding a consensus-seeking process to represent the technical community and its work in external communications. The scope includes: | ||||||
| * Technical development and its process in the the project | ||||||
| * Releases and release announcements | ||||||
| * Technical documentation | ||||||
| * Contributor onboarding and conduct | ||||||
| * Project governance | ||||||
| * Technical direction | ||||||
|
There was a problem hiding this comment. most of those points are duplicate of the above. I don't understand why we are duplicating them. There was a problem hiding this comment. See #1754 (comment) (I agree it’s better not to duplicate and just say something like "the above") |
||||||
| * The project website and download server | ||||||
| * Petition from the technical community that can be surfaced to the CPC level | ||||||
|
There was a problem hiding this comment. See #1754 (comment) - a specific example would be the org-wide vote of the pride campaign that the TSC just stewarded. There was a problem hiding this comment. I don’t quite understand in which case this would be escalated to the CPC, or why the CPC should be involved. There was a problem hiding this comment.
Suggested change
I would be fine with this too. Though it seems in another PR there's inclination to make these kind of things part of the CPC scope (to me if the CPC is willing to take over the workload of stewarding a representation, it seems fine to shed off the workload from the TSC. But then it also seems fair for projects to have their own autonomy on this - having an project-wide referendum sounds a lot more manageable than a foundation-wide referendum). |
||||||
|
|
||||||
| The TSC will define Node.js project’s release vehicles. | ||||||
RaisinTen marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| Communication on topics where the scope of the TSC intersects with that of the [OpenJS CPC][] or the [OpenJS board][] will be handled in collaboration with the other two bodies, facilitated by the TSC representative on the CPC. | ||||||
|
|
||||||
| If a Node.js-specific communication channel, such as a social media account or a discussion forum, is established by another party and used to represent the technical work or the technical community of the project, the TSC may request administrator or moderator access to ensure representation is aligned with the consensus within the project. Day-to-day operation in such channels can be delegated to another party as long as they follow the Code of Conduct, and respect the consensus seeking process before representation of the project is manifested. | ||||||
|
There was a problem hiding this comment. There is no "other party" that can establish an official channel. The only party is the holder of the trademarks - the OpenJS Foundation. We are part of the OpenJS Foundation, and we can use those trademarks. There was a problem hiding this comment. There is a fine line between being official or not - for example, the Discord wasn’t official until there was effort to make it official. Someone can also just set up a social media bot to post all the releases without declaring the bot official. Or initiatives like https://www.nodetodo.org/ https://nodeschool.io/ (no longer active, but I think you know what I mean). The passage just documents that when that happens, and the administrator wants to turn it official, the TSC may request administrator or moderator access to ensure alignment, but may not actually moderate it themselves as long as the delegate respect the general rule the community on GitHub has been following. It’s what we’ve already been doing. Whether the trademark should be granted to them is out of the scope of the TSC charter since the TSC is not in charge of the trademark (at most, we can forward communication with them to the foundation staff, which is also what we've been doing). |
||||||
|
|
||||||
| If the TSC becomes aware of external communications that appear inconsistent with the project’s consensus, it may engage with the communicating party, directly or through appropriate channels, to help align the message with the project’s consensus-seeking processes. | ||||||
|
There was a problem hiding this comment. This mixes responsibilities and a consensus-seeking approach. If this needs to be written somewhere, it's not in this section of this document. You can't do marketing and brand management by committee; it's too slow and it doesn't work (we tried this in the past). There was a problem hiding this comment. This documents that when someone speaks on behalf of the project on social media that is inconsistent with the project’s consensus, or without confirming consensus, the TSC would communicate and align the two. For example if someone that’s seen as a representative of the project - or the official account itself - declares “we’ll deprecate this feature in the next release” but there is no consensus within the project whether it should be deprecated, the TSC would communicate to them to get it corrected. This is what we’ve already been doing (not necessarily deprecation but I think you'd probably remember similar things that happened in the past). There was a problem hiding this comment. Honestly, this is tending towards way too much bureaucracy and process than what is going to be helpful/useful. Yes, we should all be careful about what we say before we're certain there's consensus but it's not something we need formal processes around. There was a problem hiding this comment. I think it's case by case on whether there needs formal process:
The idea isn't that the TSC must be very hands-on on how the representation is manifested, just that those who declares representation should ensure, at least by themselves, that the representation aligns with the consensus that's already been built, that part doesn't need involvement from the TSC, but obviously they can always ask for help from the TSC. And when the two aren't aligned, the TSC is in a position to remind them. Without granting TSC this in the charter, for example I could just go to TC39 and frame my own opinion as the Node.js's project opinion (I would not need to be explicit, just some misleading use of "we" would be more than enough, and one does not need to bring up the trademark because .js is silent), and no one has the right to correct me as long as I didn't go there as a OpenJS delegate - not that I would do it at TC39, or I generally try to open my words with "I don't speak for the project and this is just my personal impression" whenever people ask me "what's Node.js's opinion", but I don't see anything this charter or that of the CPC that grants anybody a position to correct me, so I would only be bound by my own conscience. |
||||||
|
|
||||||
| ## Section 5. Node.js Project Operations | ||||||
|
|
||||||
| The TSC will establish and maintain a development process for the | ||||||
|
|
@@ -168,4 +183,6 @@ and Contributors looking to participate in the development effort. | |||||
|
|
||||||
| [Condorcet]: https://en.wikipedia.org/wiki/Condorcet_method | ||||||
| [Consensus Seeking]: https://en.wikipedia.org/wiki/Consensus-seeking_decision-making | ||||||
| [OpenJS CPC]: https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md | ||||||
| [OpenJS board]: https://images.prismic.io/openjsf/c31b195a-83c9-4d89-9d92-d0cb8840ea20_OpenJS-Foundation-Bylaws-2023-09-18.pdf | ||||||
| [Single Transferable Vote]: https://en.wikipedia.org/wiki/Single_transferable_vote | ||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this sentence mean? Why should we mention consensus seeking here? It's already mentioned already in this doc.