EbookFoundation
/
readthedocs.org
mirror of https://github.com/EbookFoundation/readthedocs.org.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove api v3

ghowardsit
Eric Holscher 2019-02-04 11:27:47 -03:00
parent 5ba4038aa7
commit 1d846c7034
1 changed files with 40 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

93
docs/gsoc.rst
View File

@ -64,50 +64,6 @@ We will consider the priority on our roadmap as a factor,
along with the skill of the student,
in our selection process.
API V3
~~~~~~
We currently have a "v2" API that isn't well documented and doesn't allow users to write to it.
We want to continue using Django REST Framework for this,
but rethink how we're presenting our information to our users.
Currently we're showing everything as simple "models",
and we want to start exposing "methods" on our data,
similar to GitHub.
This is a large project and should only be done by someone who has done some basic API design previously.
Improve Translation Workflow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently we have our documentation & website translated on Transifex,
but we don't have a management process for it.
This means that translations will often sit for months before making it back into the site and being available to users.
This project would include putting together a workflow for translations:
* Communicate with existing translators and see what needs they have
* Help formalize the process that we have around Transifex to make it easier to contribute to
* Improve our tooling so that integrating new translations is easier
Support for additional build steps for linting & testing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently we only build documentation on Read the Docs,
but we'd also like to add additional build steps that lets users perform more actions.
This would likely take the form of wrapping some of the existing `Sphinx builders <http://www.sphinx-doc.org/en/stable/builders.html>`_,
and giving folks a nice way to use them inside Read the Docs.
It would be great to have wrappers for the following as a start:
* Link Check (http://www.sphinx-doc.org/en/stable/builders.html#sphinx.builders.linkcheck.CheckExternalLinksBuilder)
* Spell Check (https://pypi.python.org/pypi/sphinxcontrib-spelling/)
* Doctest (http://www.sphinx-doc.org/en/stable/ext/doctest.html#module-sphinx.ext.doctest)
* Coverage (http://www.sphinx-doc.org/en/stable/ext/coverage.html#module-sphinx.ext.coverage)
The goal would also be to make it quite easy for users to contribute third party build steps for Read the Docs,
so that other useful parts of the Sphinx ecosystem could be tightly integrated with Read the Docs.
Collections of Projects
~~~~~~~~~~~~~~~~~~~~~~~
@ -124,6 +80,19 @@ we would allow them to do a few sets of actions on them:
There is likely other ideas that could be done with `Collections` over time.
Autobuild docs for Pull Requests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It would be great to automatically build docs for Pull Requests in GitHub repos that our users have.
Currently we don't support this,
and it's one of our most requested features.
This would include:
* Modeling Pull Requests as a type of version alongside Tags and Branches
* Modifying how we upload HTML docs to store them in a place like S3 for long term storage
* Build integration with GitHub to send the status notifications when a PR is building and complete
Integrated Redirects
~~~~~~~~~~~~~~~~~~~~
@ -140,18 +109,36 @@ We should rebuild how we handle redirects across a number of cases:
There will also be a good number of things that spawn from this, including version aliases and other related concepts, if this task doesn't take the whole summer.
Autobuild docs for Pull Requests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Improve Translation Workflow
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It would be great to automatically build docs for Pull Requests in GitHub repos that our users have.
Currently we don't support this,
and it's one of our most requested features.
Currently we have our documentation & website translated on Transifex,
but we don't have a management process for it.
This means that translations will often sit for months before making it back into the site and being available to users.
This would include:
This project would include putting together a workflow for translations:
* Modeling Pull Requests as a type of version alongside Tags and Branches
* Modifying how we upload HTML docs to store them in a place like S3 for long term storage
* Build integration with GitHub to send the status notifications when a PR is building and complete
* Communicate with existing translators and see what needs they have
* Help formalize the process that we have around Transifex to make it easier to contribute to
* Improve our tooling so that integrating new translations is easier
Support for additional build steps for linting and testing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Currently we only build documentation on Read the Docs,
but we'd also like to add additional build steps that lets users perform more actions.
This would likely take the form of wrapping some of the existing `Sphinx builders <http://www.sphinx-doc.org/en/stable/builders.html>`_,
and giving folks a nice way to use them inside Read the Docs.
It would be great to have wrappers for the following as a start:
* Link Check (http://www.sphinx-doc.org/en/stable/builders.html#sphinx.builders.linkcheck.CheckExternalLinksBuilder)
* Spell Check (https://pypi.python.org/pypi/sphinxcontrib-spelling/)
* Doctest (http://www.sphinx-doc.org/en/stable/ext/doctest.html#module-sphinx.ext.doctest)
* Coverage (http://www.sphinx-doc.org/en/stable/ext/coverage.html#module-sphinx.ext.coverage)
The goal would also be to make it quite easy for users to contribute third party build steps for Read the Docs,
so that other useful parts of the Sphinx ecosystem could be tightly integrated with Read the Docs.
More info here: