Merge pull request #5210 from rtfd/gsoc-2019

Update our GSOC page for 2019

docs/gsoc.rst

@@ -1,12 +1,13 @@
 Google Summer of Code
 =====================
 
-.. note:: Thanks for your interest in Read the Docs!
-          We are working hard to update the ideas list now that we are accepted in GSOC.
-          Please give us a little while to work on things,
-          and check back on this page for updates.
+.. 
+    .. note:: Thanks for your interest in Read the Docs!
+              We are working hard to update the ideas list now that we are accepted in GSOC.
+              Please give us a little while to work on things,
+              and check back on this page for updates.
 
-Read the Docs is participating in the Google Summer of Code in 2018.
+Read the Docs is hoping to be in the Google Summer of Code in 2019.
 This page will contain all the information for students and anyone else interested in helping.
 
 Skills
@@ -63,43 +64,71 @@ We will consider the priority on our roadmap as a factor,
 along with the skill of the student,
 in our selection process.
 
-Refactor & improve our search code
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Collections of Projects
+~~~~~~~~~~~~~~~~~~~~~~~
+
+This project involves building a user interface for groups of projects in Read the Docs (`Collections`).
+Users would be allowed to create, publish, and search a `Collection` of projects that they care about.
+We would also allow for automatic creation of `Collections` based on a project's ``setup.py`` or ``requirements.txt``.
+
+Once a user has a `Collection`,
+we would allow them to do a few sets of actions on them:
+
+* Search across all the projects in the `Collection` with one search dialog
+* Download all the project's documentation (PDF, HTMLZip, Epub) for offline viewing
+* Build a landing page for the collection that lists out all the projects, and could even have a user-editable description, similar to our project listing page.
+
+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.
 
-Currently we're using a homegrown library for Elastic Search.
-There is a new `elasticsearch-dsl <http://elasticsearch-dsl.readthedocs.io/en/latest/>`_ library that we should be using.
-This project will include:
+This would include:
 
-* Improving our search indexing
-* Refactoring how we "model" our search data to use elasticsearch-dsl Models
-* Add additional search data into our indexes, like the programming languages, type of document (tutorial, api, etc.) and other data for users to filter by
-* (Optional) Improve the UX of the search for users in various ways
+* 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
 
-Finish YAML config
-~~~~~~~~~~~~~~~~~~
+More info here: 
 
-Currently we have a basic :doc:`configuration file <config-file/v1>` for Read the Docs.
-It's still considered beta,
-and there are a number of features that it doesn't support.
-We need to support everying users can currently do from our website dashboard inside the YAML file,
-and then plan a smooth transition path from the database UI to the YAML file.
+* https://github.com/rtfd/readthedocs.org/issues/1340
+* https://github.com/rtfd/readthedocs.org/issues/2465
 
-This is a *large* project and will likely require a good deal of understanding of both Python as well as web technologies.
-We have a `starting list of issues <https://github.com/rtfd/readthedocs.org/milestone/28>`_ put together,
-but there will be much more work.
 
-API V3
-~~~~~~
+Build a new Sphinx theme
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-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.
+Sphinx v2 will introduce a new format for themes,
+supporting HTML5 and new markup.
+We are hoping to buid a new Sphinx theme that supports this new structure.
 
-Currently we're showing everything as simple "models",
-and we want to start exposing "methods" on our data,
-similar to GitHub.
+This project would include:
 
-This is a large project and should only be done by someone who has done some basic API design previously. 
+* A large amount of design, including working with CSS & SASS
+* Iterating with the community to build something that works well for a number of use cases
+
+This is not as well defined as the other tasks,
+so would require a higher level of skill from an incoming student.
+
+Integrated Redirects
+~~~~~~~~~~~~~~~~~~~~
+
+Right now it's hard for users to rename files.
+We support redirects,
+but don't create them automatically on file rename,
+and our redirect code is brittle.
+
+We should rebuild how we handle redirects across a number of cases:
+
+* Detecting a file change in git/hg/svn and automatically creating a redirect
+* Support redirecting an entire domain to another place
+* Support redirecting versions
+
+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.
 
 Improve Translation Workflow
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -114,8 +143,8 @@ This project would include putting together a workflow for translations:
 * 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
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+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.
@@ -132,48 +161,15 @@ It would be great to have wrappers for the following as a start:
 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
-~~~~~~~~~~~~~~~~~~~~~~~
-
-This project involves building a user interface for groups of projects in Read the Docs (`Collections`).
-Users would be allowed to create, publish, and search a `Collection` of projects that they care about.
-We would also allow for automatic creation of `Collections` based on a project's ``setup.py`` or ``requirements.txt``.
-
-Once a user has a `Collection`,
-we would allow them to do a few sets of actions on them:
-
-* Search across all the projects in the `Collection` with one search dialog
-* Download all the project's documentation (PDF, HTMLZip, Epub) for offline viewing
-* Build a landing page for the collection that lists out all the projects, and could even have a user-editable description, similar to our project listing page.
-
-There is likely other ideas that could be done with `Collections` over time.
-
-Integrated Redirects
-~~~~~~~~~~~~~~~~~~~~
-
-Right now it's hard for users to rename files.
-We support redirects,
-but don't create them automatically on file rename,
-and our redirect code is brittle.
-
-We should rebuild how we handle redirects across a number of cases:
-
-* Detecting a file change in git/hg/svn and automatically creating a redirect
-* Support redirecting an entire domain to another place
-* Support redirecting versions
-
-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.
-
-
 Additional Ideas
 ~~~~~~~~~~~~~~~~
 
-We have some medium sized projects sketched out in our issue tracker with the tag *Feature Overview*.
+We have some medium sized projects sketched out in our issue tracker with the tag *Feature*.
 Looking through `these issues`_ is a good place to start.
 You might also look through our `milestones`_ on GitHub,
 which provide outlines on the larger tasks that we're hoping to accomplish.
 
-.. _these issues: https://github.com/rtfd/readthedocs.org/issues?direction=desc&labels=Feature+Overview&page=1&sort=updated&state=open
+.. _these issues: https://github.com/rtfd/readthedocs.org/issues?direction=desc&labels=Feature&page=1&sort=updated&state=open
 .. _milestones: https://github.com/rtfd/readthedocs.org/milestones
 
 Thanks