Add a code of conduct #4585

New Issue

adam · 2025-12-29T18:37:57+01:00

adam commented

2025-12-29 18:37:57 +01:00

Originally created by @CKarper on GitHub (Feb 24, 2021).

Change Type

[X] Addition
[ ] Correction
[ ] Deprecation
[ ] Cleanup (formatting, typos, etc.)

Area

[ ] Installation instructions
[ ] Configuration parameters
[ ] Functionality/features
[ ] REST API
[X] Administration/development
[ ] Other

Proposed Changes

Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time.

A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don’t agree with.

Originally created by @CKarper on GitHub (Feb 24, 2021).  ### Change Type [X] Addition [ ] Correction [ ] Deprecation [ ] Cleanup (formatting, typos, etc.) ### Area [ ] Installation instructions [ ] Configuration parameters [ ] Functionality/features [ ] REST API [X] Administration/development [ ] Other  ### Proposed Changes Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don’t agree with.

adam closed this issue

2025-12-29 18:37:58 +01:00

adam commented

2025-12-29 18:37:58 +01:00

@jeremystretch commented on GitHub (Feb 24, 2021):

In my experience, codes of conduct are read only by people who don't need them, and ignored by people who do. Or, worse, people who want to be jerks study them to find loopholes which allow them to continue being jerks without technically violating the "rules."

@jeremystretch commented on GitHub (Feb 24, 2021): In my experience, codes of conduct are read only by people who don't need them, and ignored by people who do. Or, worse, people who want to be jerks study them to find loopholes which allow them to continue being jerks without technically violating the "rules."

adam commented

2025-12-29 18:37:59 +01:00

@CKarper commented on GitHub (Feb 24, 2021):

While I can certainly concede that some bad actors would abuse the CoC to start drama, I disagree that they are fundamentally flawed in the ways you suggest. Even if participants ignore them, they form a reasonable set of expectations for participants in a project. Additionally they become a tool for the team to use to deal with toxic behavior if it were to occur, so it's more an investment in the future than anything else.

Let me know if I can provide any more information or context. This issue really only exists to meet the requirements for contributing a PR. See #5855.

Was trying to meet the contribution requirements without adding workload to the maintainers.

@CKarper commented on GitHub (Feb 24, 2021): While I can certainly concede that some bad actors would abuse the CoC to start drama, I disagree that they are fundamentally flawed in the ways you suggest. Even if participants ignore them, they form a reasonable set of expectations for participants in a project. Additionally they become a tool for the team to use to deal with toxic behavior if it were to occur, so it's more an investment in the future than anything else. Let me know if I can provide any more information or context. This issue really only exists to meet the requirements for contributing a PR. See #5855. Was trying to meet the contribution requirements without adding workload to the maintainers.

adam commented

2025-12-29 18:37:59 +01:00

@jeremystretch commented on GitHub (Feb 24, 2021):

they form a reasonable set of expectations for participants in a project

This is already established within a community by the discussions which have taken place and can be referenced by newcomers. The problem with trying to codify acceptable behavior is that you've engaged in an arms race with trolls who work to circumvent it, and cry foul if you take action not strictly in compliance with the code. In practice, a code of conduct only serves to make a maintainers' job more difficult, not less.

@jeremystretch commented on GitHub (Feb 24, 2021): > they form a reasonable set of expectations for participants in a project This is already established within a community by the discussions which have taken place and can be referenced by newcomers. The problem with trying to codify acceptable behavior is that you've engaged in an arms race with trolls who work to circumvent it, and cry foul if you take action not strictly in compliance with the code. In practice, a code of conduct only serves to make a maintainers' job _more_ difficult, not less.

adam commented

2025-12-29 18:37:59 +01:00

@CKarper commented on GitHub (Feb 24, 2021):

Hard disagree that reading all prior discussion is an accessible way to find project standards. You make bare assertions that these are problems, but I don't agree.

Having a code of conduct which sets a minimum bar is not a fully codified set of "acceptable behaviors". Using an open set of standards that is in place across numerous other projects should protect against any trolling or "arms races" that could occur. While different implementations can have bias and issues, the idea of a CoC as referred to in this issue doesn't have to fettered by these problems.

If the mere idea of having a CoC is making life difficult for a maintainer, then I would respectfully suggest that perhaps the maintainer isn't behaving in a way that's compatible with a CoC. And that would be an issue worth solving.

@CKarper commented on GitHub (Feb 24, 2021): Hard disagree that reading all prior discussion is an accessible way to find project standards. You make bare assertions that these are problems, but I don't agree. Having a code of conduct which sets a minimum bar is not a fully codified set of "acceptable behaviors". Using an open set of standards that is in place across numerous other projects should protect against any trolling or "arms races" that could occur. While different implementations can have bias and issues, the *idea* of a CoC as referred to in this issue doesn't have to fettered by these problems. If the mere idea of having a CoC is making life difficult for a maintainer, then I would respectfully suggest that perhaps the maintainer isn't behaving in a way that's compatible with a CoC. And that would be an issue worth solving.

adam commented

2025-12-29 18:38:00 +01:00

@bobjacobsen commented on GitHub (Feb 24, 2021):

I'm new here, but let me comment based on my experiences with several other open source projects hosted on GitHub and elsewhere.

Once a project has reached a point where there are highly invested people doing a lot of the day-to-day work and a larger community with less active roles, discussions of adopting/imposing community standards never go well. At best, they use up a lot of time and create hard feelings. At worst, they can divide and damage a project.

In a perfect world, of course this doesn't happen. But we're not talking about a perfect world. We're talking about a world where a lot of people have different levels of investment in a project and that's started to become differences of opinion about behavior. That's hard. It's particularly hard when people feel like a code of conduct is being imposed on them, on top of all the other stuff they're doing for a project.

So, if somebody who isn't one of the most active members wants to see a code of conduct adopted/imposed, I recommend they start with themselves. "I'm not trying to get anybody to do this, but I propose to act in accordance with (link). If you're also willing to do this, give it this a thumbs up". If a large part of the community signs on, great, a consensus has been achieved: Discussion can start with that. If not, not.

But it doesn't help to tell other people how to behave, particularly if they're doing more than you are.

@bobjacobsen commented on GitHub (Feb 24, 2021): I'm new here, but let me comment based on my experiences with several other open source projects hosted on GitHub and elsewhere. Once a project has reached a point where there are highly invested people doing a lot of the day-to-day work and a larger community with less active roles, discussions of adopting/imposing community standards _never_ go well. At best, they use up a lot of time and create hard feelings. At worst, they can divide and damage a project. In a perfect world, of course this doesn't happen. But we're not talking about a perfect world. We're talking about a world where a lot of people have different levels of investment in a project and that's started to become differences of opinion about behavior. That's hard. It's particularly hard when people feel like a code of conduct is being imposed on them, on top of all the other stuff they're doing for a project. So, if somebody who isn't one of the most active members wants to see a code of conduct adopted/imposed, I recommend they start with themselves. "I'm not trying to get anybody to do this, but I propose to act in accordance with (link). If you're also willing to do this, give it this a thumbs up". If a large part of the community signs on, great, a consensus has been achieved: Discussion can start with that. If not, not. But it doesn't help to _tell_ other people how to behave, particularly if they're doing more than you are.

adam commented

2025-12-29 18:38:00 +01:00

@DanSheps commented on GitHub (Feb 24, 2021):

Going to have to suggest we pass on this for a couple of reasons:

I read the CoC, I am familiar with CoC's and they should be a two way street (as any contract generally should be), this CoC is not. It does not address non maintainer/contributor participants in any way.
We have gotten by without one for a decent amount of time. All maintainers here are generally professional people and we don't need to have a code of conduct to conduct ourselves professionally. Sometimes we are terse, but that can happen in any situation and a CoC isn't going to stop that, nor should it.
You failed to follow the contributing guidelines and opened a PR before waiting for an issue to be accepted. I understand you also need to show the proposed CoC but there are other ways to do that.

Is there a particular driver for bringing this up?

@DanSheps commented on GitHub (Feb 24, 2021): Going to have to suggest we pass on this for a couple of reasons: 1. I read the CoC, I am familiar with CoC's and they should be a two way street (as any contract generally should be), this CoC is not. It does not address non maintainer/contributor participants in any way. 2. We have gotten by without one for a decent amount of time. All maintainers here are generally professional people and we don't need to have a code of conduct to conduct ourselves professionally. Sometimes we are terse, but that can happen in any situation and a CoC isn't going to stop that, nor should it. 3. You failed to follow the contributing guidelines and opened a PR before waiting for an issue to be accepted. I understand you also need to show the proposed CoC but there are other ways to do that. Is there a particular driver for bringing this up?

adam commented

2025-12-29 18:38:00 +01:00

@CKarper commented on GitHub (Feb 24, 2021):

Once a project has reached a point where there are highly invested people doing a lot of the day-to-day work and a larger community with less active roles, discussions of adopting/imposing community standards never go well. At best, they use up a lot of time and create hard feelings. At worst, they can divide and damage a project.

The most active and familiar team members should absolutely have the most say in the technical direction of an open source product. But should they get special permission to not treat others in a reasonable manner? I don't think they should. The amount of work done doesn't excuse anyone from meeting reasonable baseline interpersonal behaviors.

Going to have to suggest we pass on this for a couple of reasons:

I'm happy to work with the team to find a CoC they find acceptable. As mentioned earlier, this issue is around the proposal to just have a CoC, not any particular instance of one. The proposed CoC absolutely addresses non-maintainer behaviors, and in fact, hands the reigns of enforcement directly to maintainers. I'd be happy to dig into the details of interpretation in the PR of this particular CoC if it helps clear up any confusion.

I don't believe the team has actually been fine without one, and is not a welcoming pace for a project that aims to be an "industry standard". The behavior of the maintainers being "generally professional" is not a very high standard, and the terseness is only one facet of that.

While you're right that I didn't strictly follow the unreasonably high bar to have permission to submit a PR, I clearly am making a good faith effort to accompany my issue with actionable content. Hiding behind bureaucracy is exactly what you're claiming "others" would do if a CoC existed.

Those are the drivers behind this issue.

The general tenor of the feedback so far is that a CoC is some kind of restriction on the existing team, and it is definitely not. It is a commitment that a minimum set of standards will be met with everyone involved in interacting with this project moving forward. That does include the maintainers, but also requires that any future contributors or participants meet the standard as well. It is simply clear expectation setting.

@CKarper commented on GitHub (Feb 24, 2021): > Once a project has reached a point where there are highly invested people doing a lot of the day-to-day work and a larger community with less active roles, discussions of adopting/imposing community standards never go well. At best, they use up a lot of time and create hard feelings. At worst, they can divide and damage a project. The most active and familiar team members should *absolutely* have the most say in the technical direction of an open source product. But should they get special permission to not treat others in a reasonable manner? I don't think they should. The amount of work done doesn't excuse anyone from meeting reasonable baseline interpersonal behaviors. > Going to have to suggest we pass on this for a couple of reasons: I'm happy to work with the team to find a CoC they find acceptable. As mentioned earlier, this issue is around the proposal to just *have* a CoC, not any particular instance of one. The proposed CoC absolutely addresses non-maintainer behaviors, and in fact, hands the reigns of enforcement directly to maintainers. I'd be happy to dig into the details of interpretation in the PR of this particular CoC if it helps clear up any confusion. I don't believe the team has actually been fine without one, and is not a welcoming pace for a project that aims to be an "industry standard". The behavior of the maintainers being "generally professional" is not a very high standard, and the terseness is only one facet of that. While you're right that I didn't strictly follow the unreasonably high bar to have permission to submit a PR, I clearly am making a good faith effort to accompany my issue with actionable content. Hiding behind bureaucracy is exactly what you're claiming "others" would do if a CoC existed. Those are the drivers behind this issue. --- The general tenor of the feedback so far is that a CoC is some kind of restriction on the existing team, and it is definitely not. It is a commitment that a minimum set of standards will be met with everyone involved in interacting with this project moving forward. That does include the maintainers, but also requires that any future contributors or participants meet the standard as well. It is simply clear expectation setting.

adam commented

2025-12-29 18:38:01 +01:00

@jeremystretch commented on GitHub (Feb 24, 2021):

This conversation has run its course.

@jeremystretch commented on GitHub (Feb 24, 2021): This conversation has run its course.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#4585