[HTTPS-Everywhere] Initial Review of Issues and Pull Requests

[Kate Chapman]

Hi All,

As part of my engagement with EFF and HTTPS Everywhere I reviewed Github Issues and PR with the goal of looking for quick wins and sore spots. Based on that I have put together a suggested "To Do" list. I wanted to share this with everyone here and see what you think.

Thank you!

-Kate

# Drive By and First Time Contributors

HTTPS Everywhere has many more users than contributors, with millions of
installs. In the past 2 years, 62 unique people have committed to the
HTTPS Everywhere repo, though 20% have fewer than 5 commits each. While
this is overall a small number of commits, all code contributors start
with an initial commit. (These statistics do not count attempted initial
commits where changes are requested in the pull request and when the
initiator does not respond the pull request is closed.)

Some first-time contributors start by submitting pull requests.
Encouraging maintainers to finish pull requests, helping these initial
contributors, will reduce the later work that would be required if
someone created a completely new pull request to add a ruleset for a
site. In order to be able to effectively do this, we need to recruit
more more maintainers.

A more typical first contribution is reporting an issue. Those reports
generally fall into three different categories: requesting a ruleset for
a site that does not have one, reporting a bug in an existing ruleset,
and reporting a bug in the HTTPS Everywhere plugin itself. It would be
useful to initially evaluate these tickets to determine their
complexity; then, we would mark those that are relatively simple
rulesets with a "New Contributor Friendly" label, the then encourage the
submitter to try to develop the ruleset. If they are unresponsive,
someone else can attempt it later. Currently the label "Good Volunteer
Task" exists, but not a more explicit label for "New Contributor Friendly".

To do:

recruit maintainers
find and surface "New Contributor Friendly"

# Old Issues

Currently, there are over 500 issues open in the HTTPS Everywhere repo,
the oldest being over 4 years old. Having so many open issues makes it
difficult to prioritize and sort through them. If we further develop a
road map, we could close some issues and comment that they are features
that aren't on our horizon.

Here is a sample of some old issues that I think should be considered
for closing:

Issues that seem unlikely to be fixed or developed:

CA Extended Validation Indication Disappears (blocking all HTTP
request): https://github.com/EFForg/https-everywhere/issues/1004
Allow custom exclude rules:
https://github.com/EFForg/https-everywhere/issues/296

Issues that are old and likely no longer an issue:

Large issues:

Some issues are huge and are likely to remain open forever. Breaking
them into smaller pieces will help make the issues more approachable.

Better unittest coverage:
https://github.com/EFForg/https-everywhere/issues/427
Test and debug the HTTPS Everywhere experience in China (and other very
hostile networks): https://github.com/EFForg/https-everywhere/issues/1000

There are other issues that are bugs that should kept open as they have
been recently reverified.

These issues are a sampling and there are certainly others. With further
discussion and guidelines someone could go through and close other
issues as well.

To do:

further develop roadmap
close unlikely to fix issues

# Discussions

Discussions currently happen through GitHub issues, which only reach
those people who are following every update to the repository.
Discussions should be moved to the mailing list instead, to have a wider
audience. Once decisions are made, each decision should be documented
either as an action in a GitHub issue or through an update to documentation.

To do:

Move discussions to mailing list
Start practice of consistently documenting decisions

# Increase Number of Maintainers

For most of these improvements to take place, we need to increase the
number of maintainers. Currently, the role of most maintainers is to
approve ruleset pull requests. More reviewers are needed to go through
the existing pull request backlog, but also asking other volunteers to
step up could help with some of the other issues highlighted above.

To do:

Personally encourage more contributors to review rulesets
Signal-boost guidance on how to review and triage issues and PRs

-- 
Kate Chapman
Twitter: @wonderchook Skype: kateachapman
Mobile/Signal: +1 703 673 8834


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20180228/d24c6773/attachment.sig>