You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NumFOCUS has released a new Code of Conduct and has asked projects to consider whether they would like to adopt the NumFOCUS Code of Conduct. Our current CoC was based on the SciPy CoC in force at that time. We didn't put a huge amount of time developing it, partially because we have so little experience with what a CoC should include, etc.
Most of the discussion in our community meeting was positive toward leaning on the work the CoC committee has done, and the relative expertise of those folks. We also like the idea that an event could be reported to a group other than the NetworkX Steering Council, which could likely be personally involved.
The main concern with adoption of the CoC is that it might impose a complex process on the project -- or include a procedure for removal of a person from the project -- without project approval.
We should continue to collect opinions from folks not at the meeting. And we should start the process of adoption of the NumFOCUS CoC, at least enough to find out what is involved. Dan will coordinate this activity and others should prepare for a vote at the next community meeting 4/25).
Please add comments here about what we discussed and what else we should consider. Thanks!
The text was updated successfully, but these errors were encountered:
I'm +1 on adopting this-- I think, there are a lot of good things in it and it's pretty detailed as well and having additional external support in CoC violation issues would definitely benefit the project and the community around it.
The main concern with adoption of the CoC is that it might impose a complex process on the project -- or include a procedure for removal of a person from the project -- without project approval.
I share this concern. Adopting the CoC as-is may delegate significant decision-making authority to the NumFOCUS CoC Working Group. So, maybe we can modify our governance document(this maybe?) to specify the powers and limitations of the CoC WG and how those would interact with the powers of community and the Steering council. But, i think it would be more helpful if NF could update their CoC and add things like -- what should be the procedure if the project members vote against the decision of the CoC WG. I personally would want the two parties(i.e. NF CoC WG and NetworkX community(i.e. networkx users, contributors, core devs, SC)) to be equally accountable to each other and have properly documented procedures to question each other. I'm interested in knowing how others see the two working together in the future?
Apologies in advance if the following points are already covered—I’ve only skimmed the CoC pages on NF website. If so, I’d appreciate pointers to the relevant sections in CoC:
The CoC seems more inclined towards NF events and not that detailed when it comes to reporting issues within a small community around an open source project. The reporting form also seems to have questions more inclined to events as compared to project-communities.
Which brings me to my second concern-- how will NF ensure anonymity in small project-based communities?
I'm assuming CoC WG consist of volunteers only -- I couldn't find a list of CoC WG members. My concern is that- if it's all volunteer based then what measures or procedures will they be following to ensure that each report gets enough time and attention and does not get delayed responses? Maybe it would be worth including a paid NF staff member to dedicate time in this WG.
NumFOCUS has released a new Code of Conduct and has asked projects to consider whether they would like to adopt the NumFOCUS Code of Conduct. Our current CoC was based on the SciPy CoC in force at that time. We didn't put a huge amount of time developing it, partially because we have so little experience with what a CoC should include, etc.
Most of the discussion in our community meeting was positive toward leaning on the work the CoC committee has done, and the relative expertise of those folks. We also like the idea that an event could be reported to a group other than the NetworkX Steering Council, which could likely be personally involved.
The main concern with adoption of the CoC is that it might impose a complex process on the project -- or include a procedure for removal of a person from the project -- without project approval.
We should continue to collect opinions from folks not at the meeting. And we should start the process of adoption of the NumFOCUS CoC, at least enough to find out what is involved. Dan will coordinate this activity and others should prepare for a vote at the next community meeting 4/25).
Please add comments here about what we discussed and what else we should consider. Thanks!
The text was updated successfully, but these errors were encountered: