- Create a dedicated "Reporting bugs" page to learly document
where and how bugs should be reported.
- Drop "Reporting issues" section from the Contributing guide.
- Delete "Bug report guidelines" page.
Removes a paragraph about posting in the new members stream to get
help finding issues to work on from the first contribution part of
the contributing guide.
Also updates the remaining section about posting to new members as
a way to introduce yourself with a link to the community norms and
offering positive feedback as well as constructive criticism.
We should rearrange Zulip's developer docs to make it easier to
find the documentation that new contributors need.
Name changes
Rename "Code contribution guide" section -> "Contributing to Zulip".
Rename "Contributing to Zulip" page -> "Contributing guide".
Organizational changes to the newly-named "Contributing to Zulip":
Move up "Contributing to Zulip", as the third link in sidebar index.
Move up renamed "Contributing guide" page to the top of this section.
Move up "Zulip code of Conduct", as the second link of this section.
Move down "Licensing", as the last link of this section.
Move "Accessibility" just below "HTML and CSS" in Subsystems section.
Update all links according to the changes above.
Redirects should be added as needed.
Fixes: #22517.
This page contains a lot of other material related to GSoC than
just project ideas.
We would also want to add a redirect from the old URL to the new
one from the RTD admin page.
We recently changed /developer-community to /development-community.
Now that this change is in production, we can also migrate the
external links in our ReadTheDocs documentation.
The main focus is on improving the instructions around claiming issues
to try to create less issue claiming spam.
Additionally, we haven't done a detailed update in a few years, and
some of the content is stale/irrelevant.
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.
This has for a while been our only active Google Groups mailing list,
and given that folks will guess security@ as our security contact, we
might as well just standardize on that.
Also tweak some ambiguous text; it wouldn't be appropriate for us to
issue a CVE for e.g. an operational issue only affecting us.
"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.