Skip to content

Latest commit

 

History

History
52 lines (34 loc) · 4.34 KB

CONTRIBUTING.md

File metadata and controls

52 lines (34 loc) · 4.34 KB

Contributing

If you are interested in contributing, here are some ground rules:

Communication

First, please read through our code of conduct, as we expect all our contributors to follow it.

Second, before starting on a project that you intend to contribute to the unity-ssldc, we strongly recommend posting on our Issues page and briefly outlining the changes you plan to make. This will enable us to provide some context that may be helpful for you. This could range from advice and feedback on how to optimally perform your changes or reasons for not doing it.

Document Style

Basics

  • All contributions will be received as PRs - just read the recommendation below first please! 😁
  • This is intended to be a technical reference for other colleagues in the security community, so the language and style should reflect that.
  • You'll notice that our language is fairly casual for this type of content, but keep the language civil/mild and avoid using too much lingo when writing, and when using an abbreviation, please provide he definition upon its first use. Also refer to our our official Code of Conduct.
  • Given the nature of this content, it's ultimately meant for developers writing the code, not just security folks looking at it - it's not productive to write an article that not everyone can understand. Keep things simple, but accurate.

Article Updates

Spelling and Grammar changes

Simply update the spelling of the article and do a PR. For simple changes like this, we won't be updating the Authorship or contributor section in the article itself, but your PR will be in the changelog.

New Content and Substantial Changes

If you want to contribute new security recommendations or research to an additional article, provide the PR ensuring that you're maintaining the original articles style and template as closely as reasonable.

If mutliple people contributed to the content, please include their names in the Contributors section at the end of the article.

New Articles and the Template

If creating a new article, we'd recommend taking a look at the Contribution_Template that we have to help improve consistency in the article formatting. We're open to article in differing format, but variance from the template will necessitate a review of the articles layout to ensure it's readable and logical.

For new articles, please ensure everyone who has substantially contributed to the article is appropriately credited as an author.

Attribution and Credit

An important aspect of this body of work is that contributors are recognized for their work. As such, authors and contributors will be recognized in the content of the Markdown file, not just by their names in the Git changelogs. Above this is discussed a bit, but we'll repeat it here for clarity:

  • Authors: Original Authors of an article will be given credit at the top of the article. This will include the month and year the content was originally written.
  • Contributors: People who have provided new research or recommendations to an article will be added as a Contributor in the appropriate section at the bottom of the page, along with the month and year their contribution was made.
  • Minor changes: Minor changes (spelling, grammar, etc.), will be accepted directly as PRs, with the contributors account logged in the changelog for that PR.

Review Process

Currently the review process will be ad-hoc within the Unity Security team. All approval decisions will be the responsibility of Unity. We'll do our best to adapt and adjust according to the rate and quality of contributions as we move forward.

If you disagree with an editorial decision, we'll be open to the conversation. Ultimately, however, if an agreement can't be reached, then forking this into a new version may be the most appropriate option.

Forking

Please fork! We'd love to see industry specific versions, or flavors, of this SSDLC being developed. We know that some of the best practices here may be too specific, or not specific enough, in areas that are important to your business or industry. Assuming all this goes well, we'll likely have our own fork to more narrowly focus recommendations for game developers and studios.


All contributions are governed by the Apache 2.0 license.