From 63d7a308407aace4b232dea611ecfcea461345db Mon Sep 17 00:00:00 2001 From: Andreas Jaeger Date: Wed, 14 Nov 2018 17:18:38 +0100 Subject: [PATCH] Enable sphinx warnings Tread warnings as errors - and fix all warnings. Change-Id: I864fbc9cbe4a11c163505a10471dee869bcb1328 --- doc/source/opencommunity.rst | 6 +++--- doc/source/opendevelopment.rst | 6 +++--- tox.ini | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/source/opencommunity.rst b/doc/source/opencommunity.rst index bfe8651..406134a 100644 --- a/doc/source/opencommunity.rst +++ b/doc/source/opencommunity.rst @@ -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. diff --git a/doc/source/opendevelopment.rst b/doc/source/opendevelopment.rst index 8958071..f492533 100644 --- a/doc/source/opendevelopment.rst +++ b/doc/source/opendevelopment.rst @@ -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 diff --git a/tox.ini b/tox.ini index 1506e6c..7089b99 100644 --- a/tox.ini +++ b/tox.ini @@ -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