As a community, we want to help each other, provide constructive feedback, and make a better product. Of course, our code of conduct must be followed at any time.
NUKE is a personal project that was made open-source to let the whole community benefit from it free of charge but also "as is". Like many open-source projects, it is primarily maintained and developed by a single person. Some of the most time-consuming tasks around the project are:
- Development of the NuGet package itself (C#, .NET, MSBuild)
- Collecting CLI metadata (.NET ClI, MSBuild, Docker, +30 others)
- Integration with CI/CD services (Azure Pipelines, GitHub Actions, TeamCity, ...)
- IDE extensions (VSSDK, ReSharper SDK, IntelliJ SDK, Kotlin, JVM, Gradle)
- Website (JavaScript, TypeScript, React, Docusaurus)
- Hosting (Azure, Cloudflare, Algolia, Fathom)
- Documentation, presentation slides, and blog posts
- Helping in GitHub issues/discussions, Slack, and Discord
- Talking at conferences and meetups, including travel
- Promotion on Twitter and Mastodon
This list should give you an impression of what it took to make NUKE what it is today and what it continuously takes to move it forward. Obviously, though, there's only a limited amount of time a single person can dedicate besides their personal life and real job without burning out.
Therefore, everything that benefits a larger audience is prioritized over digging into issues that only affect a single or few individuals. Please don't take offense when your issue or pull request is not getting the attention you were hoping for. It is simply a time management decision.
There are several minimal to zero efforts you can make to show your support for the project:
- Give the GitHub project a star (and tell your team)
- Follow @nukebuildnet and @nuke@dotnet.social
- Upvote, share and comment on our content (see #mentions on Slack)
- Talk about NUKE on social media and let others know where it can help (tag us!)
The above points are considered somewhat of the norm in exchange for using the project free of charge.
There are plenty of ways to show your commitment to the project and strengthen its longevity. These are typically tied to contributing time or money but also allow for prioritizing your own issues in return:
- Convince your company to sponsor
- Sponsor personally (e.g., when the project improves your work performance reviews)
- Take ownership of a tool wrapper or CI/CD service (.NET CLI, GitHub Actions, etc.)
- Write a blog post or give a meetup talk (let us know!)
- Help others in GitHub issues/discussions or on Slack and Discord
If you need help with any of the above suggestions, don't hesitate to ask!
Evaluate whether your topic is going to be a valid issue:
- Have you read and searched the documentation?
- Have you checked the FAQ?
- Is your issue more of a question? Ask on GitHub discussions, Slack, or Discord!
- Have you checked existing/closed issues? Is your version behind?
- Have you read the relevant changelog notes?
- Have you verified it's not an external tool issue? Invoke the command manually!
- Don't file issues for tool wrappers. Send a pull request instead!
- Refrain from debating the governance or state of the project out of your own interests (see consumer expectations & sustainability contributions)
Choose one of the issue templates and fill it out as well as possible. This includes, but is not limited to:
- State the issue as short as possible (more likely there's time to comprehend it)
- Use markdown for code, logs, and other special text fragments
- Don't paste images when they're showing log output or exception messages
- Refrain from making demands or expressing disappointment (see consumer expectations & sustainability contributions)
When an issue is of poor quality, or it is evident that the guidelines haven't been read, it will be closed without any further response.
Once the triage label is removed from your issue, you will know how it is seen from the project's perspective:
- Issues labeled as
area:cicdorarea:toolsusually can be fixed in user code- Custom arguments can be wrapped in local extension methods
- Additional steps in CI/CD configuration generation can be added through inheritance
- If your issue is labeled as
good first issue, consider sending a pull-request
The issue will be addressed sooner or later depending on the priority, available time, and your commitment to the project. In rare cases, it might also be closed due to missing resources.
In your own interest of getting a pull-request merged (timely):
- Discuss non-trivial changes in an issue
- Make sure your employer allows contributions
- Branch your work off from the
developbranch - Get familiar with the coding conventions
- Aim for qualitative and readable code
- Follow the coding style of the existing codebase
- Make sure the project builds, and all tests pass
- Don't copy/paste chunks of code, even when it's meant as a draft
- Drafting APIs is okay as long as you're ready to finish it later
- Add tests when meaningful, particularly when there is a related test class already
- Link the issue it relates to (unless it's trivial)
- Check all the applicable boxes
For tool wrappers (e.g. .NET CLI), also note the following remarks:
- Copy/paste as much as possible
- Cover at least a full command with all its arguments
- Use tags for formatting in
help<c>for inline code<a>for links<ul>/<ol>for lists<em>for emphasized text<para/>in between paragraphs (as opposed to<p>...</p>)
- Don't explicitly define
secret: false(it's the default) - Don't provide
default: xxx(it's obsolete) - Test your changes by calling the
GenerateToolstarget - Don't commit generated code; it will be done manually once per release
- Don't bother to rebase your pull-request if commits have been force-pushed
- Don't "push" your pull-request (see sustainability contributions)