NPO-Accounting/npo-accounting-ikiwiki
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Developer documentation stuff.

Browse source
This commit is contained in:
Bradley M. Kuhn 2013-11-15 13:45:46 -05:00
parent 915d39fe2d
commit 15203fc6db
2 changed files with 17 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
ExistingProjects/EvaluationTemplate.mdwn
View file

@ -68,4 +68,7 @@ does, so I think it's tough to do it as a list of questions.
### Evaluation of the [[Community Health|UseCases/CommunityHealth]]
- Is the [[license both determined as Free Software by FSF and OSI-approved|USeCases/CommunityHealth#license-approved]]?
- Is the [[license GPL-compatible||UseCases/CommunityHealth#gpl-compatible]]?
- Does the project [[require assignment of copyright or a CLA to get code upstreamed|UseCases/CommunityHealth#no-cla-for-profit]]?
- Does the project
[[require assignment of copyright or a CLA to get code upstreamed|UseCases/CommunityHealth#no-cla-for-profit]]?
- Is there good [[developer documentation|UseCases/CommunityHealth#dev-docs]]?
- How easy it to [[engage as a developer with the community|UseCases/CommunityHealth#dev-welcoming]]?

14
UseCases/CommunityHealth.mdwn
View file

@ -29,5 +29,17 @@ aligned.
Given that the project is going to solicit support and contributions from
501(c)(3)'s, this issue is particularly important.
## No Legal Barriers
## Developer Documentation
<a id="dev-docs"></a>
The right choice has to have an accessible codebase. Since no accounting
package yet deals with the issues specific to non-profit organizations, this
project will have to focus on bringing developers *to* the new project.
<a id="dev-welcoming"></a>
As such, the codebase needs to be accessible. Communication with the
core developers should be possible and interactive. The project should
be willing to accept new contributors who might want to make substantial
changes to the codebase.