From 614b991d059fbd697dafe2d4abbcf4a9c1200dfe Mon Sep 17 00:00:00 2001 From: amaitland Date: Tue, 15 Apr 2014 11:10:44 +1000 Subject: [PATCH 1/3] Update CONTRIBUTING.md Separated document into sections, made some formatting changes, making text bold where required. Added additional coding style guidelines Added Section on PR's and Feature Branches --- CONTRIBUTING.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8407558d0c..40b4554f7e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,7 +1,20 @@ +##CefSharp Project Contribution Guide Thanks for your interest in contributing to the project! Please follow these simple guidelines: +### General - **Please read the full contents of [the FAQ](https://github.com/cefsharp/CefSharp/wiki/Frequently-asked-questions) before submitting an issue, or posting to the Google Group. It's quite likely your question has already been answered before.** If something is unclear in the FAQ, of course feel free to ask; the idea is just to reduce the level of "noise" we have to go through, reading the same questions over and over again. - If you are unsure if something is a "bug" or a "feature", discuss it with the Google Group first. Don't cross-post: if you create an issue, and all the information is contained there, that's perfectly enough. There's no reason to also post it to the group; it just creates "line noise". The project maintainers are very busy people like you and me, and things will sometimes take a few weeks (or in worst case, more) to answer. If you are in a rush - do your very best to investigate the problem thoroughly; if possible, fix the bug yourself and submit a pull request. - Before creating a GitHub issue or pull request, try looking through the list & issue archives to make sure the issue at hand hasn't been raised before. [Google](http://www.google.com) can also be helpful: just typing "cefsharp appdomain" for example (when trying to see whether AppDomain support has been discussed before) will often give you helpful results. -- *Please* follow existing coding style when submitting pull requests. Most importantly, *use spaces* - do not use tabs (which is the default setting for C++ projects in Visual Studio). The "preview" function when creating a Pull Request on GitHub is very useful - please use it. + +### Coding Style +- **Please** follow existing coding style when submitting pull requests. +- Most importantly, **use spaces** - do not use tabs (which is the default setting for C++ projects in Visual Studio). - The "preview" function when creating a Pull Request on GitHub is very useful for identifying whitespace issues - please use it. +- Max number of columns (insert here), please format your code accordingly +- When adding new files, please prepend the standard license disclaimer (just copy and paste from another source file) - Do your best to follow these guidelines but don't be afraid to make mistakes when trying to apply them. We are all novices in the beginning. + +### Pull Requests/Feature Branches +- Please limit your changes to a logical grouping, keeping changesets small increases the likely hood they will be merged +- If you then want to make subsequent changes, it's actually best to not do them before the feature is merged. Please wait for feedback/review before progressing. This greatly improves our ability to review your changes and dramatically increases the likelihood they will be merged in a timely fashion. +- If you wish to keep progressing on your work, please maintain a feature branch independent of the branch referenced by your pull request. From your WIP branch you can selectively merge in changes to the PR branch as required. +- In general, it's much better to be "too granular" PR's that contain "change-the-world"-kind of changes, which usually tend to lag behind a lot longer before getting merged (if they ever will...). From 7ab9e3c41ed16a69131eb50864ac19d80cc35164 Mon Sep 17 00:00:00 2001 From: jornh Date: Tue, 15 Apr 2014 05:30:45 +0200 Subject: [PATCH 2/3] Update CONTRIBUTING.md Added 132 columns --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 40b4554f7e..7f62e9bf25 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -9,7 +9,7 @@ Thanks for your interest in contributing to the project! Please follow these sim ### Coding Style - **Please** follow existing coding style when submitting pull requests. - Most importantly, **use spaces** - do not use tabs (which is the default setting for C++ projects in Visual Studio). - The "preview" function when creating a Pull Request on GitHub is very useful for identifying whitespace issues - please use it. -- Max number of columns (insert here), please format your code accordingly +- Max number of columns are 132, please format your code accordingly - When adding new files, please prepend the standard license disclaimer (just copy and paste from another source file) - Do your best to follow these guidelines but don't be afraid to make mistakes when trying to apply them. We are all novices in the beginning. From ffeaa0a7ed522f76a43f35b08420378d0afa44ce Mon Sep 17 00:00:00 2001 From: jornh Date: Tue, 15 Apr 2014 09:31:14 +0200 Subject: [PATCH 3/3] Update CONTRIBUTING.md + 'with' in the last bullet point Minor spelling nit --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7f62e9bf25..e12ac48045 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -14,7 +14,7 @@ Thanks for your interest in contributing to the project! Please follow these sim - Do your best to follow these guidelines but don't be afraid to make mistakes when trying to apply them. We are all novices in the beginning. ### Pull Requests/Feature Branches -- Please limit your changes to a logical grouping, keeping changesets small increases the likely hood they will be merged +- Please limit your changes to a logical grouping, keeping changesets small increases the likelihood they will be merged - If you then want to make subsequent changes, it's actually best to not do them before the feature is merged. Please wait for feedback/review before progressing. This greatly improves our ability to review your changes and dramatically increases the likelihood they will be merged in a timely fashion. - If you wish to keep progressing on your work, please maintain a feature branch independent of the branch referenced by your pull request. From your WIP branch you can selectively merge in changes to the PR branch as required. -- In general, it's much better to be "too granular" PR's that contain "change-the-world"-kind of changes, which usually tend to lag behind a lot longer before getting merged (if they ever will...). +- In general, it's much better to be "too granular" with PR's that contain "change-the-world"-kind of changes, which usually tend to lag behind a lot longer before getting merged (if they ever will...).