The repositories you contribute to should ideally have a file
.github/CODEOWNERS.
If that is so, suggest to the maintainer edits to that file so that you will be automatically assigned PR reviews for those PR's that
will affect the areas or files that you “own” (ie, that you are usually responsible for).

Branches you create to submit PRs should be deleted as soon as the PR is resolved (either merged or closed for other reasons).
Make a point of deleting a branch when you see its corresponding PR has been merged.

To remove old branches from your clone of the repo, run this Git command from time to time:

Does your project use wikis or projects? If not, disabling those options will reduce some
cognitive load, un-clutter the web UI, and prevent absent-minded collaborators from contributing wiki pages or other stuff that
nobody is using nor paying attention to.

In https://github.com/w3c/<REPO>/settings/installations, under Services, you may want to add a handy
service; like an IRC notifier, or a Twitter bridge (depending on the nature of your repository, of course).

Ideally, this file should not contain filenames or patterns that are associated to specific OS's, IDE's or
editors; eg .DS_Store (MacOS), Thumbs.db (Windows), *~ (emacs).
The other contributors don't need to know about the different types of droppings your tools produce, and there are cleaner ways to
ignore files locally, like
configuring your Git to do so.

Usually applicable only to repositories containing software (not specs), and assuming the language/platform detected in the
repository is understood and supported by GitHub; find out
in their help pages.

Enable vulnerability alerts in settings, here:

https://github.com/w3c/<REPO>/settings#vulnerability-alerts-feature

Once enabled, vulnerabilities will be shown highlighted in two places:

At the top of the main page of the repo; ie https://github.com/w3c/<REPO>

The specifics of Travis configuration depend greatly on the language/platform and on the dependencies and tools involved.
See the documentation or browse existing repositories using Travis to learn more.

You may want to add your new repository containing a spec in
Repository Manager (akaAsh-Nazg).
This is a tool that helps with IPR managements from public contributors; check with the Systeam if in doubt.

From time to time, check the list of all branches in the project, https://github.com/w3c/<REPO>/branches/all, and
delete the ones that aren't being used; branches that are not ahead of the default branch, and branches associated to PRs that
are either merged or closed already, are definitely good candidates for removal.
If in doubt, ask the author of the branch.