Concerns about the Content vs Code Responsibilities

[avivkeller]

(I think this kinda walks the line between a https://github.com/nodejs/web-team and https://github.com/nodejs/nodejs.org issue, but since the guidelines are maintained here, I've opened this here)

---

Ref: #7972 (comment)

The Content vs Code guidelines asserts that the Website Team is not an editorial team, except in areas with no assigned team or Working Group (WG) ownership, in which case we become the default editors. However, in practice, I feel that this distinction is not always clear or consistently applied.

For example, we (the Website Team) already write and maintain a significant portion of the website’s content. If we are generating content, shouldn't we also be trusted with editorial responsibility for that content? Saying we aren’t an editorial team, while also being responsible for unowned content and contributing a large amount ourselves, seems like a contradiction.

Additionally, there are many areas where content may technically fall under a WG’s domain, but that WG doesn’t actively maintain or engage with that content on an ongoing basis. In those cases, it’s unclear whether the Website Team is expected to defer entirely or if we are allowed to step in and help improve it.

In my opinion, the Website Team should be allowed to act as an editorial team across all content on the site, while WGs have final say in their areas of expertise.

[ovflowd]

One of the biggest reasons of me explicitly wanting the website team not to be responsible of the technical content being served here is to remove ourselves from the equation. Often this content must be phrased extremely well and written well and in a way that accurately represents the truth. Although we maintain the website, we're not by default experts of its content. We might be good in writing code, but not necessarily have a deep understanding of the inner workings of each one of the technical pieces of content that are written here. This can easily lead to us publishing misleading or poorly written content and actually causing harm.

It's also the reason why I often try to steer this team in being neutral and by default inclined with the direction the TSC wants to do something, although still providing advisory opinions on matters that relate to the website marketing, UX, branding, design and structure as I believe we have a better practical and professional understanding of these topics (or at least a few of us have)

But the reality is that membership on this team, as pretty much anyone with enough contributions can join, doesn't automatically mean you're knowledgeable about these topics, and my ultimate goal is to prevent situations where members of our team share their opinions, review PRs or block PRs based on knowledge they lack. Surely, everyone's opinions are welcome and respected, but surely I also want to avoid unfortunate situations that encourage us to make decisions that shouldn't be, imo, ours to be done, or at the very least, in some, we shouldn't be the final ones to say yes or no to have something landing.

It might not make much sense, but my ultimate goal is to protect our members, steer towards a direction where we avoid arrogant stances, even if best intended, that can put us in difficult positions. Wanting or not, the Website is the Frontline of the project.

[ovflowd]

Note that my commentary isn't a +1 or a -1 take on your arguments, just me trying to clarify my intents and past actions as a maintainer of this team.

[avivkeller]

One of the biggest reasons of me explicitly wanting the website team not to be responsible of the technical content being served here is to remove ourselves from the equation.

I understand the reasoning here. The idea is to prevent the Website Team from becoming a bottleneck or an accidental authority on technical content we are not qualified to vet. That concern is valid. At the same time, I think recognizing editorial responsibility in some areas does not mean taking on full responsibility for technical accuracy. Editorial work is not only about being the technical expert, we can still defer to the right Working Group or expert for the final word.

Although we maintain the website, we're not by default experts of its content.

This is true. Maintaining the site does not mean we automatically understand every technical detail. But that is also true of many editorial teams. Editing content is not about owning the subject, it is about helping improve how it is presented. If content is unclear, outdated, inactive, or otherwise in need of improvement, it makes sense for us to step in and help move it forward rather than let it stall due to unclear ownership.

I am not saying the Website Team should make final decisions on technical correctness. I am saying the Website Team should be allowed to make editorial decisions. If we are responsible for a large portion of the content, it makes sense for us to have a role in maintaining its quality.

[Eveeifyeve]

I have a feeling that the authors should have the right to maintain the code base if they don't then make an issue requesting authors, similar to how nixpkgs works. By far that way governance can happen as well as maintainability is responsible by the person.

[avivkeller]

I have a feeling that the authors should have the right to maintain the code base if they don't then make an issue requesting authors, similar to how nixpkgs works. By far that way governance can happen as well as maintainability is responsible by the person.

Take this analogy: imagine Apple contributes an article on quality coding practices. If Orange wants to update or improve that article, should they have to ask Apple for permission? Should Apple be allowed to indefinitely gatekeep the content they originally wrote?

I don't think that's a viable solution.

[Eveeifyeve]

I have a feeling that the authors should have the right to maintain the code base if they don't then make an issue requesting authors, similar to how nixpkgs works. By far that way governance can happen as well as maintainability is responsible by the person.

Take this analogy: imagine Apple contributes an article on quality coding practices. If Orange wants to update or improve that article, should they have to ask Apple for permission? Should Apple be allowed to indefinitely gatekeep the content they originally wrote?

I don't think that's a viable solution.

Well I don't think your getting what I am saying...... I think your too caught up working for node or esm to not get what I am trying to say.... I request that you take a look at nixpkgs govermance before replying to my comments again.

You also gatekeeping a pr that could be not good because of this issue. I meant to keep it open governance structure and responsibilities is the maintainability is in the author. However a member of the nodejs team can gate keep based on open policies.

That's why I request that you take a look at nixpkgs govermance before replying to my comments again.

[avivkeller]

You also gatekeeping a pr that could be not good because of this issue.

That is off-topic to this discussion. My comments on any given issue hold no weight here. Also, for the record, I am not "gate-keeping" content, I am blocking a pull request that I feel should not land for reasons I specified on a seperate thread, but again, off-topic.

I meant to keep it open governance structure and responsibilities is the maintainability is in the author. However a member of the nodejs team can gate keep based on open policies.

There are significant problems with that approach. Most importantly, we can’t reliably assume that the original author will remain responsible for future changes to their contribution. For example, if Apple contributes something and Orange later modifies it incorrectly, is Apple now accountable? And what happens when a third contributor, like Banana, wants to help... but is deterred because contributing means inheriting long-term maintenance responsibilities?

There's a large difference between adding a package to a registry and writing an article.

Regardless, this issue is specifically about the responsibilities of the Node.js Website Team, and not individual contributors.

[Eveeifyeve]

You also gatekeeping a pr that could be not good because of this issue.

That is off-topic to this discussion. My comments on any given issue hold no weight here. Also, for the record, I am not "gate-keeping" content, I am blocking a pull request that I feel should not land for reasons I specified on a seperate thread, but again, off-topic.

I meant to keep it open governance structure and responsibilities is the maintainability is in the author. However a member of the nodejs team can gate keep based on open policies.

There are significant problems with that approach. Most importantly, we can’t reliably assume that the original author will remain responsible for future changes to their contribution. For example, if Apple contributes something and Orange later modifies it incorrectly, is Apple now accountable? And what happens when a third contributor, like Banana, wants to help... but is deterred because contributing means inheriting long-term maintenance responsibilities?

There's a large difference between adding a package to a registry and writing an article.

Regardless, this issue is specifically about the responsibilities of the Node.js Website Team, and not individual contributors.

Honestly as I said you haven't done research please do not comment on my comments until you do further research, also your comments hold emotional weight. I am not going to go here and argue with someone who doesn't understand what I am trying to say and no research has put into thought, because I am not that person who wants to deal with same with @ahm4dd.

[avivkeller]

I've hidden this conversation as Off-Topic, since it strays from the original issue described.

[AugustinMauroy]

I had already suggested two things to address this issue:

• Have a team review the content and its relevance. And that pings the teams (from node core) for an in-depth review. This has not been implemented.
• Link resources to a core team to force content review. This is what has been done in Expand CODEOWNERS to each learn section owner/advocate #7292. But not all articles can be covered by a specific team.