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

[Maxim Nazarenko]

Hello all!

As suggested, I am starting a discussion on the mailing list :)

Issue: new rulesets are untested and therefore likely to break websites.

Proposed solution: let volunteers test new rulesets before declaring
them stable and delivering them to GA

Proposed flow for a new ruleset:
    i) Do some basic sanity checks and merge it into master asap,
_clearly marking it as unstable_, a new attribute in <ruleset> tag
will do nicely
    ii) Release unstable ruleset to volunteers asap
    iii) Wait for reaction. If everything is good -- declare a ruleset
stable and mark it as such. Deliver it to GA

Expected results: New rulelsets are released volunteers for testing.
Testers are expected to know how to disable bad rulesets and report
issues.

Technical changes:
    i) Update build script to include unstable rulesets only in
nightly builds and clearly mark unstable rulesets -- this is actually
the easiest part, I can do a pull request for it
    ii) Setup nightly/per commit builds and delivery.

Possible blocker: Release Firefox requires all add-ons to be signed.

TBD: When is a ruleset considered stable?

Waiting for comments/suggestions. Thank you!

Best regards,
Maxim Nazarenko

On 1 March 2018 at 02:14, Kate Chapman via HTTPS-Everywhere
<https-everywhere at lists.eff.org> wrote:
> 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
>
>
>
> _______________________________________________
> HTTPS-Everywhere mailing list
> HTTPS-Everywhere at lists.eff.org
> https://lists.eff.org/mailman/listinfo/https-everywhere