Status

 RESOLVED 

BlockingTSC Election 2020
OutcomePassed
Minutes Link2020 02 20 TSC Minutes

Overview of Proposal

Several questions have been raised against the way voters are selected for the TSC election. Typical questions include: 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.

It is proposed to build on that status quo with a couple of additions.

Formal Proposal(s)

Adopt the selection process used in 2019, using the Hyperledger get_contributors tool run against "all" and "labs" repositories to harvest from github everyone that has contributed to the codebases in the past year. The CAs also email all of the workgroups' and Task Force Chairs to determine who has contributed other Documentation or technical artifacts. In addition, a form is available for people to petition about other technical contributions that have been made.

CAs are entitled to clean the list from what they believe are fraudulent entries with notification to the TSC members.

Excluding changes such as bug fixes, improvements, and changes made to reflect the evolution of the list of Hyperledger repositories modifications to the get_contributors tool that impact the produced list must be endorsed by the TSC.

Action Items

  • Type your task here, using "@" to assign to a user and "//" to select a due date

Reviewed By

72 Comments

  1. Hart Montgomery

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

  2. Dan Middleton

    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. Hart Montgomery

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

  3. Arnaud J Le Hors

    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. Dan Middleton

      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. Christopher Ferris

        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. 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

          1. Tracy Kuhrt

            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. Christopher Ferris

              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. Ry Jones

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

    2. Tracy Kuhrt

      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. Ry Jones

        They were included

        1. Christopher Ferris

          we should make that clear in the revised bylaws.

  4. Mark Wagner

    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. Dan Middleton

      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. Todd Little

        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. Christopher Ferris

          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. Todd Little

            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. Todd Little

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

        1. Christopher Ferris

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

        2. Christopher Ferris

          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. Todd Little

            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. Todd Little

    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. Christopher Ferris

    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. Ry Jones

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

      1. Christopher Ferris

        really?

        1. Ry Jones

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

          1. Vipin Bharathan

            It is more of an administrative log, right?

            1. Ry Jones

              Here are the event types that are in the audit log.

              Vipin Bharathan Christopher Ferris

      2. Todd Little

        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. Vipin Bharathan

          1. Todd Little

            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. Christopher Ferris

              there we go!

              1. Todd Little

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

                1. Christopher Ferris

                  Unless I'm mistaken, you already had.

  7. Vipin Bharathan

    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. Todd Little

    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. Arnaud J Le Hors

    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. Hart Montgomery

      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. Christopher Ferris

    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. Hart Montgomery

      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. Silas Davis

    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. Christopher Ferris

    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. Silas Davis

      I find this convincing...

    2. Hart Montgomery

      I agree with this approach in theory.  But what if I add my entire company's email directory as committers to my changes?  We haven't seen stuff like this before (at least on a large scale), but I worry that this last election was acrimonious enough that someone might try something like this (or "people" might just do it for demonstration purposes).  I can't come up with a good solution that resists mildly malicious behavior, though, so I'm not sure we can do much better than allowing the LF staff to eliminate obviously ridiculous things.

      1. Dan Middleton

        If we formalize that the criteria is a commit we have not made anything worse. We only simplify and clarify the existing practice. Already today someone could try to abuse the commit process.

        1. Hart Montgomery

          That's true, but it might be something we want to write the rules to avoid in the future.

  13. Mark Anthony Morris

    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.   

    1. Dan Middleton

      I hope that people don't associate the value of participation in HL with the ability to vote in a steering committee election.

      This committee is meant to address issues in the development of the software. The idea of the committee and its election is that the people working on the code address these issues rather than hiring staff.

  14. Dan Middleton

    Based on how this discussion has tended to go in circles I recommend we break it into two pieces.

    1. Criteria for voting
    2. Mechanism for harvesting voter contact info

    The first point is a governance decision from the TSC. The second point is more or less an engineering problem, and I recommend that we let HL staff solve that as committees don't solve engineering problems well. If staff finds that some policy would aid the solution (e.g. all committers must register a valid email address) then the TSC can approve that policy when it is recommended.

  15. Mark Wagner

    I am really concerned about everything being code centric. I feel strongly that there are other ways to provide valuable technical contributions without writing code.

    1. Mark Anthony Morris

      I couldn't agree more. Long before any code is committed an idea must manifest; for ideas come long before any code. Design should follow the idea, and finally code. Many can contribute valuable ideas that lead to great code that many want, and will use. But a shallow or narrow pass that hinders ideas will produce shallow and narrow code, suited to specific interests groups, rather than a large and inclusive community with the aspiration to grow, and populate the work effort, ultimately illustrated by the code quality, and interest in the community. It would be beneficial, I would think, to have many progress from idea to code as the code progresses from PoC (lab), alpha, beta, and ultimately production. The system facilitates many more minds and hands from a diverse population, then is exhibited today. Perhaps, I am off base, and the code should be segregated into small controlled groups of vetted coders instead of open and inviting to all coders and want-a-be-coders. One must be a beginner before a world-class contributing world changing coder. Anything that presents a high bar of entry is a problem. The ability to vote for the leaders is primary to motivating participation and producing the desired outcome–great code that many want and will use; code that shapes and creates a better world for all. These are just my thoughts, and may be out of touch, or not informed enough to be helpful, and for that I apologize. My only intention is to improve the Hyperledger ecosystem, and while code is a large and prioritized component, I think little things matter, and collectively may be even be more important. Participation to me is everything and fosters growth and adoption. 

  16. Hart Montgomery

    I am hopeful that any work we have to do to satisfy DCO policies will help us make progress on this.  That being said, it still looks like there is still some fundamental disagreement on what a contribution should be.

  17. Arnaud J Le Hors

    David Huseby I must admit not to be sure what your change of status to "Blocking" is meant to convey. Can you please explain?

    1. David Huseby

      Arnaud J Le Hors the CA team is working on a number of community management initiatives this year that depend on guidance and feedback from the TSC. One of those is the plan for the 2020 TSC election. We're starting early so that we can work everything out well ahead of the summer break and get it all set up so that when we come back from break we can just hit the "go" button and execute.

      I added the "blocking" status to highlight that a particular TSC decision log item is blocking an ongoing community initiative. I know that the 2020 election plan page is still empty. I'm compiling notes from last year's election and the post-mortem analysis we did plus feedback from others. Then I plan to make a number of suggestions. Those suggestions depend on a few of the outstanding decisions.

      The intention of the "blocking" status is to indicate that certain time sensitive/ongoing initiatives are currently blocked waiting for the TSC to weigh in.

      1. Silona Bonewald

        It also can be used to show dependencies.

      2. Arnaud J Le Hors

        Ok. That makes sense. Just make sure to indicate what is being blocked when labeling an issue as blocking.

        Thanks.

  18. Christopher Ferris

    Frankly, we have a process and it works. Arguing about what is a "technical artifact" is really rather pedantic. There's an appeals process so that if you feel you should have been allowed to vote, you can make your case to the CA team. While I know that some have made the case that submitting a drive-by PR to fix a typo like 'teh' as trivial, there's a saying in show biz that "there are no small parts, just small actors". The saying does not apply to physical stature.

    We are an open source community. The whole organizing principle is the code. It's why we are here. Even a fix of a typo improves the quality of the code. The documents we produce are even being developed in GH in many cases. They count, surely.

    Do we extend to the Labs? I think we did that last year. There's another vector to pursue for contributions. It isn't clear to me we have a problem to solve with regards to who is eligible. The real problem is getting those who are eligible to vote.

    1. Brian Behlendorf

      While it may have seemed like things "worked" in retrospect, please understand there was a ton of hard work by LF staff behind the scenes to deal with bad data, dangling references, people not responding to emailed questions, and second-guessing from the community that placed tremendous stress on them and, while memories may be fuzzy, a non-trivial amount of dissatisfaction from the community. We pulled through, but all seemed to agree to try and address these issues for next time, and ahead of time, which is why this is being re-raised with the goal of closing it. So no, objectively, we do not have a process that "works" so well that it can't be improved.

      Here, in fact, are the specific set of 5 recommendations from HL staff to the TSC for next time and some discussion that followed:

      https://lists.hyperledger.org/g/tsc/topic/34285114

      I'll ask HL staff to come up with specific proposals, if they haven't already been made or decided upon in the decision log, for each point, so they can be iterated on and closed in prep for the election later this year. Sound good?

      BTW as per "we are an Open Source community" - aside from the requirement that the rules and election be public, there really is no consistent approach to elector qualification in the open source community. Apache sets a fairly high bar for who becomes a Member of the ASF - you have to be proposed by an existing member and voted in by a majority vote of the membership at the yearly Members meeting. Other projects have no elections process at all - it's founders appointing themselves (and new founders as old ones time out) without public accountability. Many others limit it to committers or maintainers. Even the concept of "do-ocracy" says that the more you do, the more right you have to governance. So a low low bar is not something to assume.


      1. Christopher Ferris

        We have discussed this. Yes, I am well aware of the effort and stress involved in dealing with the bad data. It relates to why I raised the DCO signature email issue - so many are unresolvable. As I suggested in chat (I believe) the onus should NOT be on staff to chase down people who left commits with bogus email addresses - it should be on the committer.

        Danno had a suggestion that might be the solution. Have a registration just like you do with federal and state elections. You register with evidence of an eligible contribution. You could have an election task force (election observers?) that vets the registrations that cannot be automatically verified (seems like pattern matching a name with a commit comment including a DCO signoff could be easily automated).

        This might serve both to remove the onus on staff, but also raise the participation rate (why register if you have no intention of voting?)

  19. Vipin Bharathan

    So in a nutshell:

    1. Anyone who contributes a technical artifact: not just from Github - A wider net will help- Ever since the first election this has been through github queries, recommendations from WG chairs, and now we should take from SIG chairs as well. Or have a process to look at wiki updates; similar to the process for Github updates. Bar for "commit harvesting" does not matter.
    2. Have initiatives to increase participation in the elections. I had proposed several nudges. Some people feel that there is no problem with this; but let numbers tell the story. What is the participation rate? 30%? Of 600 or so electors that works out to 200 people.


    1. Brian Behlendorf

      These two goals seem to be at odds with each other - the wider you cast the net for participation, the lower the bar for elector qualification, the far more likely that your participation percentage will be lower. Someone who only contributed a single PR or a paragraph to a wiki page is much less likely to bother with participating in the election, and be a lower-quality voter as they are less likely to know the candidates or read up on their background so just lean on the names that seem most familiar. By contrast, if you were to limit elector candidacy strictly to active maintainers, it's likely your participation rate will be much higher, since they are much more heavily affected by TSC decisions than the average drive-by.

      1. Vipin Bharathan

        Last year, we had about 200 voted out of 600 to 800 emails. Around 25%-30% participation. You may be right that as we cast a wider net we will have lower participation %. However, the number of voters may increase. This is why we need better choice architecture as well as a better GOTV effort. And clean reachable emails. Let us put this place as we can demonstrate that we are making an effort to make this governance better.

  20. Gari Singh

    So do we have a proposed date for the 2020 election?  A proposed timeline for opening and closing nominations?  As I recall, one "complaint" was that there was not enough notice.  I believe we plan to notify people earlier this year?  But perhaps we should just add entries to the community calendar(s) as soon as we have dates?

    1. Christopher Ferris

      TSC Election timing was resolved. Elections in Oct and prep in September.

  21. Arnaud J Le Hors

    I added a formal proposal that I plan to put up for vote next week. Please, comment with specific proposed changes to the text if you want to see anything different.

    1. Hart Montgomery

      Thanks!  That captures what I wanted to add.

    2. Mark Wagner

      I am ok with the formal proposal but I have a little nit about the confluence process. Is there a way to clear the "reviewed by" check boxes when you modify the page ?

      1. Arnaud J Le Hors

        Not that I know of but I have to admit that the thought crossed my mind that maybe I should uncheck all the review boxes on saving after my edits. Maybe that's just a convention we could use: i.e., if the page is significantly modified, then uncheck all review boxes before saving.

        Not as automatic as you might like but would still achieve the same result.

  22. Vipin Bharathan

    I have added " and SIG chairs" as SIGs are a source of technical contribution as well.

  23. Christopher Ferris

    But, SIGs are not under the purview of the TSC. They are a function of the Governing Board. It is unclear that the intent of the original charter is satisfied unless the SIGs start to have a direct, meaningful impact on the projects.

  24. Vipin Bharathan

    The charter speaks of technical contributions; it is very clear. It does not make the distinctions that you are suggesting in your comment Christopher Ferris