openinfra
/
four-opens
Code Issues Proposed changes

Enable sphinx warnings 

Tread warnings as errors - and fix all warnings.

Change-Id: I864fbc9cbe4a11c163505a10471dee869bcb1328
This commit is contained in:
Andreas Jaeger 2018-11-14 17:18:38 +01:00
parent b3bd57cf18
commit 63d7a30840
3 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/source/opencommunity.rst
View File

@ -48,7 +48,7 @@ project.
Getting the current stake-holders input and buy-in is key to the success.
Typically a mission statement is developed in the early days of the project
when there are fewer contributors, which makes it critical€”and as a bonus, a
when there are fewer contributors, which makes it critical and as a bonus, a
bit easier--to have an open discussion and process. Similarly, changing the
mission statement should not be taken lightly, and can be a challenging process
as the community grows and there are a broader range of perspectives. A good
@ -173,8 +173,8 @@ normal development community and must be shared with your users and the
ecosystem at large. Don't assume that you know all of the barriers that your
community members may face. Take the extra steps to pro-actively ask them to
identify the challenges they face in trying to contribute and then break down
barriers to participation — whether those barriers are time zones, culture,
gender, age, education, etc€¦ Supporting a diverse set of leaders, both
barriers to participation whether those barriers are time zones, culture,
gender, age, education, etc. Supporting a diverse set of leaders, both
geographical and by organization, can help reinforce this participation and
will ultimately make for a stronger community.

6
doc/source/opendevelopment.rst
View File

@ -20,10 +20,10 @@ in which contributions are evaluated on a level playing field. The metrics for
evaluating a patch can include:
- Correctness: does the code include tests of its functionality?
- Quality Assurance: does the code integrate with other projects and not introduce
regressions?
- Quality Assurance: does the code integrate with other projects and
not introduce regressions?
- Documentation: does a new feature include documentation on what
it does and how to properly configure it?
it does and how to properly configure it?
- Purpose: does the code implement a feature identified in the open design process?
Automation, like automated unit, integration, and style checking, can go a long

2
tox.ini
View File

@ -18,5 +18,5 @@ commands =
deps =
-r{toxinidir}/test-requirements.txt
commands =
sphinx-build -b html -d doc/build/doctrees doc/source doc/build/html
sphinx-build -W -b html -d doc/build/doctrees doc/source doc/build/html