[HTTPS-Everywhere] Initial Review of Issues and Pull Requests
nz.phone at mail.ru
Wed Feb 28 17:01:37 PST 2018
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
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!
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!
> # 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:
> 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:
> 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
More information about the HTTPS-Everywhere