[Request for Discussion] OSS - Leveraging Existing Communities (5.2.A)

[mattbailey0]

As part of the Open Source Pilot, Section 5.2.A requires the following:

Leverage Existing Communities. Whenever possible, teams releasing custom-developed code to the public as OSS should appropriately engage and coordinate with existing communities relevant to the project. Government agencies should only develop their own communities when existing communities do not satisfy their needs.

For discussion: what are things agencies should keep in mind when working with existing communities related to an open source project? For example, what do agencies need to know about contributing to a community maintained project? What should an agency that is developing a new project in a space where a robust community is already doing work?

[mattbailey0]

Relatedly, section 5.2.D requires agencies to:

Engage with the Community: Similar to the requirement in the Administration’s Open Data Policy, agencies should create a process to engage in two-way communication with users and contributors to solicit help in prioritizing the release of source code and feedback on the agencies’ engagement with the community.

[nawglan]

A lot of the bigger open source communities have a mailing list archive. When you have an issue with a product they maintain, often a search through the mailing list archive will be helpful in pointing you to a solution. If not, you can at least indicate that it seems to be a new issue.

Also, try to not rewrite the wheel. Perl for example has a vast amount of contributed code available through CPAN. Ruby and other languages have a similar setup. Try to use their code and if you find a bug, report it back to them with a patch that fixes it if you can. Using CPAN (http://search.cpan.org) as an example, each module or package on CPAN has a bug tracker through which bugs and patches can be reported back to the maintainer of that code. There are also links to the code repository for the modules that you can submit a pull request or patch, etc.

Mostly, be respectful of the existing community and they will be helpful back.

[kitsushadow]

Transparency of issues, template for issue creation, and good communication with issue creators; these three components create a medium through which issues can be easily understood, replied to, and worked on.

[jbjonesjr]

It's become a paradigm that projects will include a file of title contributing.md that talks about the process of contributing to any individual project. This often discusses approval process, submission steps, code format and other project specific information.

This paradigm should be made clear to those participating in existing communities.

[camfindlay]

Agree re: contributing.md this also often includes things like any Contributor License Agreement or copyright assignment/cross licensing that contributors need to be aware of if they are going to submit patches etc. We explicitly mentioned the contributing file in the New Zealand Government open source licensing framework since it's a good thing to address up front :+1:

[froi]

The team now has a dedicated person that actively engages in this. @RicardoAReyes is hard at work reaching out to communities and many of them are excited about Code.gov.

A number of community focussed files have been added to all of our repos:

• Code of Conduct
• Issue Template
• Pull Request Template
• Contributing.md

If this conversation should/needs to remain open, I suggest moving this conversation to our code-gov repo as it involves all our repositories.

We'll wait a couple of days before closing this.