What counts as a technical artifact? How can we collect valid email addresses so that people can be sent ballots?
This is a can of worms. It's going to be very difficult to stop potentially malicious behavior without affecting honest users.
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.
I'm going to list every email address in my company in my next commit then .
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?"
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.
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 'firstname.lastname@example.org' or 'email@example.com'. Obviously, this will lead nowhere, which I suspect is a source of frustration for Ry Jones.
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
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.
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.
Yes. I am having this problem right now on GitHub.
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.
They were included
we should make that clear in the revised bylaws.
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.
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.
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?
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.
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.
As working groups are supposed to maintain meeting minutes that include the participants, isn't that enough evidence of technical participation?
Lurking on a call is not evidence of contribution. We aren't giving out participation trophies.
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.
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.
I would propose TSC membership and voting is limited to those individuals that have participated in the technical aspects of Hyperledger. This may include:
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?
Sort of. We can export the audit log, but it doesn't show every action by every user, sadly.
The audit log is not what I expected it to be.
It is more of an administrative log, right?
Here are the event types that are in the audit log.
Vipin Bharathan Christopher Ferris
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.
There is also the contributors macro that can yield a list of contributors based upon their contributions.
there we go!
Does that mean I qualify as a technical contributor?
Unless I'm mistaken, you already had.
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.
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.
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.
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?
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.
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.
Powered by a free Atlassian Confluence Community License granted to The Linux Foundation. Evaluate Confluence today.