The [issue tracker](https://github.com/PointCloudLibrary/pcl/issues) is
The [issue tracker](https://github.com/PointCloudLibrary/pcl/issues) is
the preferred channel for [bug reports](#bugs) and
the preferred channel for submitting [pull requests](#pull-requests) and
[submitting pull requests](#pull-requests), but please respect the following
[bug reports](#bugs), but please respect the following
restrictions:
restrictions:
* Please **do not** use the issue tracker for personal support requests (use
* Please **do not** use the issue tracker for personal support requests (use
...
@@ -23,6 +23,39 @@ restrictions:
...
@@ -23,6 +23,39 @@ restrictions:
respect the opinions of others.
respect the opinions of others.
<aname="pull-requests"></a>
## Pull requests
Good pull requests - patches, improvements, new features - are a fantastic
help. They should remain focused in scope and avoid containing unrelated
commits.
**Please ask first** before embarking on any significant pull request (e.g.
implementing features, refactoring code), otherwise you risk spending a lot of
time working on something that the project's developers might not want to merge
into the project. Please read the [tutorial on writing a new PCL class](http://pointclouds.org/documentation/tutorials/writing_new_classes.php#writing-new-classes) if you want to contribute a
brand new feature.
If you are new to Git, GitHub, or contributing to an open-source project, you
may want to consult the [step-by-step guide on preparing and submitting a pull request](https://github.com/PointCloudLibrary/pcl/wiki/A-step-by-step-guide-on-preparing-and-submitting-a-pull-request).
<aname="checklist"></a>
### Checklist
Please use the following checklist to make sure that your contribution is well
prepared for merging into PCL:
1. Source code adheres to the coding conventions described in [PCL Style Guide](http://pointclouds.org/documentation/advanced/pcl_style_guide.php).
But if you modify existing code, do not change/fix style in the lines that
are not related to your contribution.
2. Commit history is tidy (no merge commits, commits are [squashed](http://davidwalsh.name/squash-commits-git)
into logical units).
3. Each contributed file has a [license](#license) text on top.
<aname="bugs"></a>
<aname="bugs"></a>
## Bug reports
## Bug reports
...
@@ -62,109 +95,53 @@ Example:
...
@@ -62,109 +95,53 @@ Example:
> merits).
> merits).
<aname="pull-requests"></a>
<aname="license"></a>
## Pull requests
## License
Good pull requests - patches, improvements, new features - are a fantastic
PCL is 100% [BSD licensed](LICENSE.txt), and by submitting a patch, you agree to
help. They should remain focused in scope and avoid containing unrelated
allow Open Perception, Inc. to license your work under the terms of the BSD
commits.
License. The corpus of the license should be inserted as a C++ comment on top
of each `.h` and `.cpp` file:
**Please ask first** before embarking on any significant pull request (e.g.
implementing features, refactoring code), otherwise you risk spending a lot of
```cpp
time working on something that the project's developers might not want to merge
/*
into the project. Please read the [tutorial on writing a new PCL class](http://pointclouds.org/documentation/tutorials/writing_new_classes.php#writing-new-classes) if you want to contribute a
* Software License Agreement (BSD License)
brand new feature.
*
* Point Cloud Library (PCL) - www.pointclouds.org
<aname="checklist"></a>
* Copyright (c) 2014-, Open Perception, Inc.
### Checklist
*
* All rights reserved.
Please use the following checklist to make sure that your contribution is well
*
prepared for merging into PCL:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
1. Source code adheres to the coding conventions described in [PCL Style Guide](http://pointclouds.org/documentation/advanced/pcl_style_guide.php).
* are met:
But if you modify existing code, do not change/fix style in the lines that
*
are not related to your contribution.
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
2. Commit history is tidy (no merge commits, commits are [squashed](http://davidwalsh.name/squash-commits-git)
* * Redistributions in binary form must reproduce the above
into logical units).
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
3. Each contributed file has a [license](http://pointclouds.org/documentation/tutorials/writing_new_classes.php#licenses) text on top.
* with the distribution.
* * Neither the name of the copyright holder(s) nor the names of its
### Suggested process
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
Adhering to this process is the best way to get your work included in the
*
project:
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
1.[Fork](http://help.github.com/fork-a-repo/) the project, clone your fork,
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
and configure the remotes:
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
* COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
```bash
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
# Clone your fork of the repo into the current directory
* BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;