...

@DynamicProperty( description = "The description of the dynamic property would go here...")

and the description method of Component Properties and Relationships

PropertyDescriptor.Builder()
        .name("Property Name")
        .description("The description of the Property would go here...")
 
Relationship.Builder()
        .name("name-of-the-relationship")
        .description("The description of the relationship would go here... ")
        .build();

When the documentation of a processor is particularly complex (e.g, may include very long descriptions or images), a contributor may choose to use NiFi's capability to automatically link additional documentation to a processor.

In this case the contributor may extend documentation by performing changes to 'additionalDetails.html'. As described in the Developer's Guide, this file should exist within a directory whose name is the fully-qualified name of the Processor, and this directory’s parent should be named docs and exist in the 'resources' directory of a particular processor bundle.

As with other contributions, component level documentation should follow the process described in "Providing code or documentation contributions" section of this document.

...

Run into a bug or think there is something that would benefit the project?  Regardless if you have the time to provide the fix or implementation, we encourage any such items to be filed as an issue at the Apache NiFi JIRA.

Anchor
providingCodeOrDocumentationContribution providingCodeOrDocumentationContribution

Providing code or documentation contributions

...

git config --global user.email user.name@email.org

...

Windows Specific configuration
The following options provide handling of long file paths that can be troublesome as well as not using Windows style line returns.
git config --global core.longpaths true
git config --global core.autocrlf false
 

Clone a copy of the repository
...
git remote add upstream https://github.com/apache/nifi.git 

Checkout the 'master' or '1.x.0' branch
...
The issue being listed first provides easy access to the supporting ticket and ensures it is not truncated from the varied means in which commits will be viewed. 

Keeping your feature branch current 
...
$ git remote -v
origin git@github.com:apiri/nifi.git (push)
origin git@github.com:apiri/nifi.git (fetch)
upstream https://git-wip-us.apache.org/repos/asf/nifi.git (fetch)
 

Once the appropriate remote (remote name) is determined, it is possible to push the branch with your changes to GitHub through:
...
$ git push origin nifi-359
 

This will update your fork of NiFi and can be verified from your GitHub personal project page:
...
From your personal fork, a Pull Request can be opened simply by selecting the Pull Request link highlighted below.
 

This will allow specification of the your branch which has the changes, and will open a PR for review by the committers of the project.
Code Review Process
While we request that the PR begin with a single, squashed commit as the initial commit, if you continue to modify the code, please continue to make commits against the same branch. GitHub handles this process well and by pushing to the same remote branch you opened the PR from, your commits will show automatically. This way reviewers can track changes in accordance with their feedback cleanly. Please avoid using squash  or --force when making these changes, as it will overwrite the remote branch and reduce the capability to track these changes. See additional note about Rebasing and Squashing while under review below for more information.  
Code Review Process
Apache NIFI has a Review-Then-Commit (RTC) philosophy for handling all contributions.  Reviewers first ensure that the code applies and builds appropriately to the build, passes the Apache NIFI has a Review-Then-Commit (RTC) philosophy for handling all contributions.  Reviewers first ensure that the code applies and builds appropriately to the build, passes the code standards as established by the Maven profile "contrib-check."  From here, code is evaluated to ensure best practices within the NiFi framework are applied and, where applicable, that the user experience of interfacing with the contribution is consistent and any changes are backwards compatible.  This process may be iterative but works toward a final product that is then merged into the codebase. 
...
As NiFi now has a 1.0 (master) and 0.x (support) branch, pull requests (PR) must be applied to both. Here is a step-by-step guide for committers to ensure this occurs for all PRs. 

Check out the latest master
...