We have disabled CircleCI and are using GitHub Actions for automated
testing.
docs: Changed context from CircleCI to Github Actions and wrote
some documentation specific to GH Actions.
tools: Replaced env checks for CIRCLECI with GITHUB_ACTION.
README: Use GitHub Actions build status badge.
We're migrating to using the cleaner zulip.com domain, which involves
changing all of our links from ReadTheDocs and other places to point
to the cleaner URL.
"Outreach programs" I think is better phrasing than "Internship
programs", since GSoC is the main one we do these days and isn't an
internship program.
This may fail CI since it contains links to anchors on ReadTheDocs
that may race; it should fail ones the ReadTheDocs build completes.
Apparently, the CircleCI and Codecov links (and the Codecov badge)
weren't pointing specifically at master, so they'd sometimes show
state from the lastest push to a pull request, which isn't a
reasonable way to advertise whether the project's build is passing.
For now, we still need the Travis badge, since Travis is where we test the
production installation process. But ideally, we'll end up removing that too.
Pointing these at the latest release, rather than the latest version
in master, allows us to make changes to the installer and document
them properly in master, without making the instructions confusingly
wrong for people who just go to the website or the GitHub repo page
and follow instructions to install.
This should get test-documentation and test-help-documentation passing
again after we moved everything around in the last commit.
There are a lot more absolute links (generally in code comments) to
update, but they are lower-priority and can be done in a follow-up
pass.
The `<foo>` was rendering empty, I think because the Markdown
processor was interpreting it as a malformed attempt at HTML,
so that it read 'our "area:" convention'.
Now that GSoC 2017 is underway, there's no need to say much
about the application process.
That section is now very short and doesn't feel like it
really fits with the other sections around. But the remaining
content seems like interesting stuff that's nice to have
in the README so that e.g. it's linked from the repo's
front page on GitHub. Leaving further refactoring to
another day.