Open issues that could be closed?

[304NotModified]

Hi,

I really like this project!

I notice that there are many issues that could perhaps be closed. That is sometimes confusing because you no longer know what is planned or answered

Can I help with this? Or would we like to leave these issues open?

Examples:

• Moq to NSubstitute migration tool #720 - not planned (as far as I understood)
• Publish to GitHub Releases from AppVeyer #680 - not needed anymore (guess also Temp: debugging appveyor build #724)
• Substiture for ILoggerFactory.CreateLogger<T> #728 answered
• Create a spy of Func<> and make it return a specific value for testing #745 answered
• How to get the StatusCode from a IActionResult? #709 offtopic and answered
• How to name a satellite nuget package designed to work with NSubstitute? #765 answered, but getting off topic (bit confusing)

[dtchepak]

That'd be awesome! I've sent you an invite with access to manage issues and PRs if you would like to do that? (if you prefer a different approach please let me know.)

The only rule we've had for managing this stuff is we try to stay disgustingly polite with all our responses. 🤣 If you think something can be closed but aren't sure you're welcome to close with something like "Please re-open if you need further information or would like us to take another look at this."

Thanks very much for your help! ❤️

[304NotModified]

The only rule we've had for managing this stuff is we try to stay disgustingly polite with all our responses.

I find this also very important! :)

Maybe we should add a code of conduct for this?

For example: https://github.com/NLog/NLog/blob/dev/CODE_OF_CONDUCT.md

[304NotModified]

@dtchepak I will also tag some GitHub issues to make it more clear. If I made some mistakes, feel free to change the tags

[dtchepak]

I'd be happy to add a code of conduct. My only concern is around enforcement. My response times aren't great at the moment and I don't want to mislead people that I'll always be able to effectively deal with transgressions in a timely way.

Would it be acceptable to adopt parts of the Contributor Covenant Code of Conduct? The "Our Pledge" and "Our Standards" sections I think are perfect, then maybe we could have something like this:

Reporting and Enforcement
We reserve the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. If you feel this has been done in error you can contact [INSERT CONTACT METHOD].

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to [INSERT CONTACT METHOD]. We will respect the privacy and security of the reporter of any incident, and will work with the reporter to handle the incident in an appropriate manner.

(Will need to setup an appropriate reporting channel; not sure if we can email @nsubstitute/admins or a new group/team for this?)

Then can include "Attribution".

Actually just saw that earlier versions probably align more closely with how we would likely be able to deal with violations. E.g. version 1.2.0

WDYT?

[304NotModified]

I'd be happy to add a code of conduct. My only concern is around enforcement. My response times aren't great at the moment and I don't want to mislead people that I'll always be able to effectively deal with transgressions in a timely way.

Would it be acceptable to adopt parts of the Contributor Covenant Code of Conduct? The "Our Pledge" and "Our Standards" sections I think are perfect, then maybe we could have something like this:

I understand, that would be more than acceptable for me :)

(Will need to setup an appropriate reporting channel; not sure if we can email @nsubstitute/admins or a new group/team for this?)

I'm not sure about this.

Actually just saw that earlier versions probably align more closely with how we would likely be able to deal with violations. E.g. version 1.2.0

That's also fine to me :)

[dtchepak]

Hi @304NotModified ,

I really appreciate your work in sorting through all these issues! Would you be open to joining the contributers team? It would be great to get another person able to help with merging PRs.

No obligations in terms of amount of involvement or anything -- can be as little or as much as you like.

You are welcome to email me@davesquared.net if you have any questions. 🙇

[304NotModified]

Hi @304NotModified ,

I really appreciate your work in sorting through all these issues! Would you be open to joining the contributers team? It would be great to get another person able to help with merging PRs.

No obligations in terms of amount of involvement or anything -- can be as little or as much as you like.

You are welcome to email me@davesquared.net if you have any questions. 🙇

Please ask me the same question in 3 months. :)
Currently I don't have enough insights of this great library to (final) review PRs.

First a long holiday soon and than I will try to dig deep in the code

[dtchepak]

Please ask me the same question in 3 months. :) Currently I don't have enough insights of this great library to (final) review PRs.

Understood. 👍 Please let me know if you want to take this on at a later date. From your work with NLog I think you're more than qualified. ☺️

Really appreciate your contributions so far; I'm happy even if you prefer to stick to contributing in that capacity without ever taking on reviews.

Quick clarification: I'm not after reviews on in-depth changes or giving final approval to PRs from external contributors (I'm happy to review and approve those), more that I need someone to review changes I make like the release build change when other core team members aren't available (I can't approve those myself haha).

First a long holiday soon

Enjoy! Have a safe and relaxing holiday.