Page tree
Skip to end of metadata
Go to start of metadata
Status

PROPOSED 

Outcome
Minutes Link

What counts as a technical artifact? How can we collect valid email addresses so that people can be sent ballots?

From TSC Election 2019, this is who was included in the list of eligible voters:

The Community Architecture team gathers this information together first by running This tool is run against "all" and "labs" to harvest from github everyone that has contributed to the codebases in the past year.   The CA's also email all of the workgroups' Chairs to determine who has contributed other Documentation or technical artifacts.  There is also a form where people can petition about other technical contributions that have been made.

45 Comments

  1. This is a can of worms.  It's going to be very difficult to stop potentially malicious behavior without affecting honest users.

  2. Let's just make it a commit.

    I know there's still headaches getting the commit email addresses sorted out but just drawing the line at commits would remove the other hassles and ambiguities. Every working group product can and probably should be version controlled in git anyway.

    1. I'm going to list every email address in my company in my next commit then (wink).

  3. I think the question is too broad. We already accepted that we can't possibly control this completely and accepted the fact that it means someone who merely fixes a typo qualifies. But I don't think that's a real problem.

    I'm more interested in ensuring anyone who ought to be part of the process be allowed to do so. Are labs contributors included for instance? If not, I think they should be added.

    And yes, Hart, people might play games with multiple identities but the biggest problem we have right now if any is the low turnout so, I don't know that we need to worry about people trying to get more than one vote.

    I would rephrase the question to "Who are we missing on the voters list?"


    1. I speculate we don't have a turnout problem. I'd wager contributors and contributions follow a power law. People who stop in for one contribution aren't engaged enough to care about the composition of a steering committee.

      1. I tend to agree. We may, however, have an outreach problem. If your commit email address is your spam email account, it is possible that some never see the outreach from the staff. It would probably be worthwhile having the period of collecting eligible voters etc extended to ensure we are reaching them. I'd note that we have somewhere in the order of 600ish contributors annually but only about 200 of them end up with eligibility registration.
        I've also noted that sometimes the "email" address is of the form 'johndoe@johndoes-macbook-pro-2.local' or '12345678+johndoe-7@users.noreply.github.com'. Obviously, this will lead nowhere, which I suspect is a source of frustration for Ry Jones.

        1. Christopher Ferris  one tool we have, that Tracy Kuhrt started us using, is Mailmap. That repo is the start of the source of truth for this. Pull requests happily accepted. You are correct, though, that I had a lot of contributions from people for which I could not get an email address

          1. In years past, I would reach out to anyone that I knew that had a noreply email address to get the email address that they wanted to include in the vote. I would also reach out to people that had contributed under multiple email addresses to find out which they preferred for the vote. In years past, I was able to get the list of noreply and duplicate emails addresses down to under 10. The mailmap file that Ry points at is a result of the effort I put in going through the list of committers for the prior two election cycles.

            1. Good to know. It does sound like lots of work, though. Seems to me that we should be having DCO sign-offs that have legit email addresses, because the whole point is to be able to contact the contributor later, should any questions arise, etc.

              1. Yes. I am having this problem right now on GitHub.

    2. Not sure about this election cycle, but I started to include Labs in the repositories that were used for creating the list. Ry Jones could confirm this is still the case. Labs committers should be included.

      1. They were included

        1. we should make that clear in the revised bylaws.

  4. I think one of the big points of contention revolves around non coders. People in Working Groups (WG) and SIGs. Three years ago I lobbied the TSC to allow the people from Working Groups to be recognized as technical contributors. Do we want to look at allowing the same recognition to members of the SIGs ?

    Main reason for: Many contribute technical work to Hyperledger through the work in the SIG.

    Main reason against: Due to the reporting structure set up by Hyperledger, the SIGs are not under the TSC whereas all the other currently eligible voters are. The current voters are effectively voting for their representatives to serve on the TSC.


    1. If everything is a commit then it all works out automatically.

      For example if a working group member commits edits to an identity paper or a SIG member to a requirements document then everything is captured regardless of what kind of group they are or aren't a part of.

      This also forwards the goal of these activities resulting in tangible outputs rather than having recurring discussion groups without output.

      1. Getting contributions to working groups is hard enough.  If contributors must submit git commits, that's going to be just another obstacle in getting their participation.  The current model of editing working group documents in Google Docs seems to be the path of least resistance.  What would be your proposed process for commits to working group artifacts?

        1. I find this an uncompelling argument against. The whole point is to have eligibility based on contribution. This by definition involves effort be expended. Git commits are trivial, especially if we extend to git issue comments etc.

          1. Why are git commits any better than Google Docs edits?  And while a document is being created or under going significant revision, does it really need to be updated in a git repository for every edit?  I can speak from experience with the Privacy and Confidentiality WG (which still hasn't produced any contributions based upon some of the comments here) and the Performance and Scale WG, getting people to contribute in the form of edits is difficult.

      2. As working groups are supposed to maintain meeting minutes that include the participants, isn't that enough evidence of technical participation?

        1. Lurking on a call is not evidence of contribution. We aren't giving out participation trophies.

        2. Fun fact, I happen to know of some people who "participate" on multiple conflicting (in terms of time/date) WG calls at a time simply to maintain voting eligibility in the WG on calls and at f2f meetings. We were even considering adopting a similar policy for the TSC to ensure we can reach quorum. I personally think that this violates the spirit of such policies and does not comprise contribution.

          1. In the last TSC election, it was left up to the WG chair to decide if someone participated, correct?  That can address the lurking.  The key issue here is what constitutes contribution and I believe contributing to technical discussions is contribution.  Measuring that is going to be subjective, so let's leave it up to the WG chairs to decide who contributed in a WG.  That could be part of the meeting minutes,  i.e., the chair records who participated and who didn't (lurked), or just who participated. 

  5. I would propose TSC membership and voting is limited to those individuals that have participated in the technical aspects of Hyperledger.  This may include:

    1. Code contributions
    2. White paper contributions
    3. Working Group (or task forces if that's what it comes to) participation as defined by meeting attendance and contributions to working group work products
    4. Documentation contributions
    5. Others?
  6. Todd Little the charter currently includes the following:

    4.b.i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

    We extended the criteria to be eligible to WG participants that the WG chair believed had meaningfully contributed for the initial TSC election. Vague, but there was also an appeals process as articulated in the TSC elections wiki and to my knowledge there has never been complaints. I don't believe that lurking on a WG call or mailing list comprises "contribution". Hence, exactly what you suggest above. It is unclear to me that there's any controversy here, TBH and I don't think we need to change anything.

    Now, the adjacent discussion about abandoning WGs in favor of Task Forces with specific outcomes will have an impact, and hence I think that we could measure participation via comments on the wiki page for the taskforce. It has the side benefit of being able to tie the "contribution" to one's LFID which is a more reliable source of emails/contact info.

    Ry Jones I presume that we can get a list of wiki authors/editors?

    1. Sort of. We can export the audit log, but it doesn't show every action by every user, sadly.

        1. The audit log is not what I expected it to be.

          1. It is more of an administrative log, right?

      1. The wiki is using Confluence, right?  If so, Confluence has a rich set of APIs that should be able to be used to find who contributed what and their email address assuming they haven't made it private.

          1. There is also the contributors macro that can yield a list of contributors based upon their contributions.

            {"include":"authors,comments","showCount":"true","limit":"10","showLastTime":"true","contextEntityId":20021859}

              1. Does that mean I qualify as a technical contributor?  (wink)

                1. Unless I'm mistaken, you already had.

  7. Christopher Ferris   Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

    The whole discussion is about "codebase", we had to get special provisions in there for WGs etc. because the only "codebase" considered legit was github and that too because there are built-in tools to measure this.

    We should not let our tools limit us. Now that we have wiki, let us talk about how we will include contributions.  Let us not proclaim the death of WGs before they are dead.

    Also I had raised this issue before: Technical contribution from SIGs can be measured and the people in SIGs who meet the definition of contributors above should be included.

  8. Christopher Ferris I also wonder whether participation in chat and answering questions is a technical contribution.  One would hope we'd want to encourage that as much as possible as it is often the first place people end up as they get started with any HL project.  Why are git commits any more valuable than these other contributions and if they aren't more valuable is it simply a matter of its easy (easier?) to get their email address?  Besides, git commits can be gamed as pointed out by Hart Montgomery so it's unclear they're any better source of proof of contribution.

  9. I'm adding here the point Brian made in his email to the list:

    Perhaps the biggest source of public confusion, and the greatest amount of work for HL staff, was in creating the list of eligible voters from the myriad of different systems for collaboration, and then de-duping and correcting for invalid addresses.  The charter describes an eligible voter very loosely: "anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase".  It doesn't tightly define "codebase" nor does it say how much of a contribution is merited, so a one-line edit to the wiki or reporting a bug would qualify.  We are happy to see the TSC looking at redefining who's allowed to vote.  In Apache, only actual members of the ASF can vote on their board, and there is always a known good email address for reaching someone, and that persists even when individuals change jobs/employers.  In addition to other criteria like "easy to describe" and "perceived as fair and hard to game", we would also ask that "easily resolvable to a working email address" be a part of the decision on who's eligible to vote.  Any substantive change to eligibility requirements should also be turned into a proposed amendment to the Charter.

    1. I'd also like to give the HL staff some latitude in determining contributors.  As of today, I could add my entire company's email directory as contributors to a PR, and everyone would get to vote. 

      I might even suggest in addition to easily resolvable to a working email address  we add the caveat easily resolvable to a real person .  We obviously wouldn't totally prevent fraud with this and wouldn't require the HL staff to check every single email/person, but it might stop some people adding anonymized emails to contributor lists and we could use this provision as-needed in case we thought something fishy was going on.  The downside would be that anonymous contributors wouldn't get to vote.  But do we have any substantial anonymous contributors anyway?

  10. I think we need to avoid solving problems we don't have. Yes, it is a challenge to map to a resolvable email address, especially when it is not a requirement that a GH account have a resolvable email, or when the email that is used in a commit/PR is essentially bogus or occasionally an email used to collect spam. We do not have an issue where someone is trying to game the system by adding every email in his corporate directory on a commit.

    We could add a CLA requirement that would require that commits be made by those who have signed it, and have the CLA bound to the LFID and a valid, verified email (which can change over time, of course). It does add to the barrier to entry for new contributors, but if it is essentially a click-through maybe not that high a bar.

    1. We don't seem to have had any election foul play yet.  But as Ry Jones can show you, there are a lot of very easy ways to do this.  Moreover, given the discussion we've had over this last election, I think this is something we definitely want to be out in front of (and not be reacting to).  Coindesk made an article about an email sent to the TSC list regarding the election.  I can only imagine the press we would get if someone accused someone else of fraudulent election behavior, particularly if it was a credible accusation.

  11. As an anecdatum... I regularly get fairly trivial low value PRs that are someone's first contribution to Hyperledger. Often they show no sign of real engagement with the project - e.g. they correct a dead link but they have not done a find and replace to fix similar dead links. They are not entirely useless, but I have a strong suspicion that they are commit harvesting. Possible for resume purposes, possibly to get the Hyperledger contributor franchise. On the other hand they are not totally useless so maybe they should be accepted. I don't really want to give someone a vote for in the TSC elections on the basis of such contributions, but yes maybe it is a power law, and maybe we don't have a problem now. I tend to ask for them to at least address the issue more generally - which often they don't - and I make the complete change myself. So I suppose that is a form of self-regulation, but perhaps a slightly perverse incentive  to not merge commits.


    I have a feeling the `commit == franchise` might be one of those worst systems apart from all the others sort of thing. But seeing as I'm here I'll have a go. How about maintainers tag commits that are a 'non-trivial contribution' or conversely can tag commits as trivial to be excluded in the harvesting process. Or how about we have some N commits in duration D requirement?

  12. No commit is useless. All should be valued, regardless of how small. That someone gets a vote for even the most trivial of fixes is one of the perks, if you will. Could it be abused? Sure, but alternatively, someone just breaking into open source, or wanting to get involved in Hyperledger would likely start small and grow their involvement. To discount their contribution, no matter how minor as "trivial" is a sure fire way to scare people off. I'd strongly oppose imposition of some bar. If the change is inconsequential, don't merge it.

    1. I find this convincing...

  13. I would like to suggest consideration for voting rights afforded to individuals that have founded and regularly host official Hyperledger Foundation Meetups. As a founder and monthly host since 2016, I would like the right to vote, based on these merits. It takes a lot of effort to consistently educate the local Austin tech community, evangelize, and promote Hyperledger Foundation every month. I would also like to be able to be a direct force, as I think other hosts would, on the ground for new entrants, as well as promote greater participation as a live recruiting forum, and f2f ambassador to educate, encourage, and actively hold specific targeted meetups that would be group-based code commit parties. I think many new individuals, including myself, would be attracted, if they knew they would not be alone, and initial guidance and support was available via a live group session. Getting started and executing that initial commit can be intimidating and difficult for many, but once done, the initial fears are gone, and the momentum to continue participating may continue to exist.