== Lowering the Barriers to Entry

Soliciting contributions in an InnerSource community is more challenging than it is in an Open Source community for a number of reasons:

* The sheer number of potential https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] is lower in InnerSource communities.
* Contributors will want to contribute during their work time, which means they are more time constrained.
* Work in InnerSource might not necessarily be part of Contributors' official
performance goals, so time spent working on InnerSource
may seem to detract from achieving those goals.

That's why it's important for Trusted Committers to make the processes for making
contributions and onboarding https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] as frictionless as
possible. There are a number of things that can help:

* Have a good README.md in each code repository. A good README.md
explains what’s in the repository and what it can be used for. In
addition, it should provide detailed instructions on how to get, build,
test, and use the software in the repository, including information about
the license.
* Have a good CONTRIBUTING.md that outlines what is expected of the
https://innersourcecommons.org/learn/learning-path/contributor[_Contributor_]. It should answer
common questions, such as:
** How do I submit a bug report or feature request?
** Who and how do I contact if I have questions?
** What are the conventions for code style, branching or commit messages?
** What is the definition of "done" for a contribution?
** What are the process steps that govern contributions?
** What is expected of me in terms of supporting contributed code after
the contribution is accepted?
** What is the code of conduct and what are the guidelines to how the
community operates?

If you have an internal license attached to the software, which in some
companies is a prerequisite for sharing software across legal entities,
include a copy of that license _and_ an explanation of the rights and
obligations in layman’s terms.

In addition to these documentary tasks, similar to Open Source
software development it should be easy and straightforward to run and test the software
being developed locally by potential https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_], so they can start implementing and validating their contribution with as little effort as
possible.

There are two common models for making contributions:
_shared repository_ and _fork and join_. Both have advantages, and as a Trusted Committer,
you want to support both models to accommodate different needs of your
potential and current https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_].
Your Contributors will often have questions about the contribution process or about the community itself, and someone has to be available to answer these questions. 
It is therefore important for any InnerSource community to
have one or more contact persons that are available for answering such
questions. Someone from the group of Trusted Committers is usually that contact person, or else they need to make sure there is a community member "on call".

It is also important to help potential https://innersourcecommons.org/learn/learning-path/contributor[_Contributors_] determine what
contributions are needed. These can be code contributions but
also noncode contributions, such as writing documentation, creating
artwork, or organizing events. One common way to do this is to tag
"newcomer tasks" in the issue tracker used by the community or
to implement a marketplace for open tasks Contributors can use.

In summary, it is super important for InnerSource communities in a
corporate environment to keep the barriers to contributing as low as
possible to allow as many people as possible to contribute. That means providing both access to helpful
documentation and people in the community to answer any questions and to encourage collaboration. In sum, Trusted Committers should make sure that onboarding and contributing are positive experiences. 
