Date   

Invitation: [Hyperledger TSC] Arch-WG Wed. 9 PT, Mic presents: "Break... @ Tue Jan 28, 2020 9am - 10am (PST) (hyperledger-tsc@lists.hyperledger.org)

clive boulton
 

You have been invited to the following event.

[Hyperledger TSC] Arch-WG Wed. 9 PT, Mic presents: "Breaking Data Silos: Smart Contracts for Data Access and More"

When
Tue Jan 28, 2020 9am – 10am Pacific Time - Los Angeles
Calendar
hyperledger-tsc@...
Who
clive.boulton@... - organizer
hyperledger-tsc@...
Tomorrow/Wed 9 AM PT Arch-WG call will feature a presentation by MicBowman titled: "Breaking Data Silos: Smart Contracts for Data Access and More"
Sharing data is challenging. As it stands, when we share data we generally lose all practical control of it. With the ever-growing pool of data available for interesting computations, we need a way to share data appropriately. Private Data Objects is a technology that combines hardware-based trusted execution and a distributed ledger to wrap data with a smart contract that handles all access and update policies. In addition to protecting the confidentiality of the data (or rather the appropriate use of the data), executing the smart contract code in a trusted execution environment means that the policies stick with the data no matter who or where...

Going (hyperledger-tsc@...)?   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account hyperledger-tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More.


Arch-WG Wed. 9 PT, Mic presents: "Breaking Data Silos: Smart Contracts for Data Access and More"

Ram Jagadeesan (rjagadee)
 

  • Tomorrow/Wed 9 AM PT Arch-WG call will feature a presentation by MicBowman titled: "Breaking Data Silos: Smart Contracts for Data Access and More"
  • Sharing data is challenging. As it stands, when we share data we generally lose all practical control of it. With the ever-growing pool of data available for interesting computations, we need a way to share data appropriately. Private Data Objects is a technology that combines hardware-based trusted execution and a distributed ledger to wrap data with a smart contract that handles all access and update policies. In addition to protecting the confidentiality of the data (or rather the appropriate use of the data), executing the smart contract code in a trusted execution environment means that the policies stick with the data no matter who or where it is stored.

    While the Private Data Objects project in Hyperledger Labs is clearly a research prototype, concepts and code are the basis for both Hyperledger Avalon and the Fabric Private Chaincode projects.

  • https://zoom.us/my/hyperledger.community

  • Call for Mentors and Projects for 2020 Hyperledger Mentorship Program

    Min Yu
     

    Hyperledger Technical Community -

    Today, we’re excited to open the call for mentors and project proposals for the 2020 Hyperleger Mentorship Program

    Last year, the Hyperledger Mentorship Program connected 25 mentors and 17 mentees from around the globe to contribute their enthusiasm, time, and experience toward building a sustainable Hyperledger community. You can learn more about the growth of this program and 2019 mentees' work and contributions by reading our blog posts:
    If you would like to volunteer your time to teach and mentor while sharing your passion for the blockchain technology with the next generation of blockchain developers in a structured program like ours, we invite you to get involved: 
    While mentors will be on a voluntary basis, the hired mentees will be eligible to receive a stipend. The stipend will be paid in several installments provided that regular interval evaluations show the mentee is making satisfactory progress. Each mentee who has successfully completed the program will be invited and financially sponsored by Hyperledger to attend an event/conference and present their work to the broader community (specific event TBD but will be during Q3 or Q4 of this year or Q1 of the following year). 

    We look forward to your submission of a mentorship project and thank you in advance for volunteering your time to contribute to the training of the new talent pool in the Hyperledger community.

    Kind regards,
    Min
    --
    Min Yu
    Operations Manager
    The Linux Foundation
    +1(530) 902-6464 (m)


    Repo Structure Proposal

    Christopher Ferris <chris.ferris@...>
     

    Not sure if everyone interested gets the notices, but I added a proposal to the repo structure task force page to leverage a tweaked default policy for the repolinter tool that Ry had suggested.

    It seems to do a reasonable job of identifying the presence or absence of what the TODO Group recommends as best practices.


    Cheers,

    Chris


    Cannot attend today

    Gari Singh <garis@...>
     

    Hi all -
     
    I will not be able to attend the TSC call today.
     
     
    -- G

    -----------------------------------------
    Gari Singh
    Distinguished Engineer, CTO - IBM Blockchain
    IBM Middleware
    550 King St
    Littleton, MA 01460
    Cell: 978-846-7499
    garis@...
    -----------------------------------------
     
     

    ----- Original message -----
    From: "Christopher Ferris" <chris.ferris@...>
    Sent by: tsc@...
    To: Hyperledger List <tsc@...>
    Cc:
    Subject: [EXTERNAL] [Hyperledger TSC] Hyperledger Fabric quarterly report 2020 Q1
    Date: Wed, Jan 22, 2020 9:35 AM
     
     


    IDWG 2020 Q1 report

    Vipin Bharathan
     


    Re: Downtime for updates of WIKI & JIRA

    Tim Johnson <tijohnson@...>
     

    All updates have been completed and both servers are back on-line.

    On 1/22/20 8:06 AM, Tim Johnson wrote:
    The update of JIRA (jira.hyperledger.org) has been completed.

    The update of WIKI (wiki.hyperledger.org) is still underway. We expect
    to be complete within the hour.

    Tim


    Downtime for updates of WIKI & JIRA

    Tim Johnson <tijohnson@...>
     

    The update of JIRA (jira.hyperledger.org) has been completed.

    The update of WIKI (wiki.hyperledger.org) is still underway. We expect
    to be complete within the hour.

    Tim


    Hyperledger Fabric quarterly report 2020 Q1

    Christopher Ferris <chris.ferris@...>
     


    TSC Agenda for Jan 23, 2030

    Arnaud Le Hors
     

    Hi,

    The agenda for this week's call is online. This is still a light agenda but I don't want to cancel again so we'll just have a short call and if anyone wants to take the opportunity to add anything, please, go ahead.

    https://wiki.hyperledger.org/display/TSC/2020-01-23+TSC+Agenda

    Thanks.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


    Promoted Releases vs Major Releases

    Arnaud Le Hors
     

    Hi all,
    Following up on the discussion we had on our last call in December, I have now revised the proposal related to the introduction of "Promoted Releases" as a replacement for the "First Major Release" and subsequent ones.
    Please, have a look at the revised proposal and be ready to vote on tomorrow's call or comment to the wiki page if you'd like to make some amendment.

    https://wiki.hyperledger.org/pages/viewpage.action?pageId=24779174

    You will notice that I slipped in there the fix for the use of "Committer" when we mean "Maintainer" which actually relates to the Incubation Exit Criteria. I considered creating a separate issue but as Silona pointed out this is really a bug fix and not a policy decision so it seemed overkill.

    Regards.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


    Re: [Hyperledger Technical WG China] [i18n] Status report on translation of Fabric docs

    Yang Cheng
     

    Hi, Sara!

    I agree with you, Transifex has good features like manage updates, but it's really inefficient, we have tried transifex for months and amlost finished Fabric 2.0 alpha translation, by the end we changed back to Github.

    Let's work togethor and find a better way for translating. Keep connecting and if you have any idea please share with us.

    And there is a i18n(https://chat.hyperledger.org/channel/i18n) channel in hyperledger chat, welcome to join the channel and discuss with us.


    --
    程阳
    Yang Cheng
    great_cy_ang@...

    At 2020-01-20 17:36:14, "Sara Garifullina" <garifullina@...> wrote:

    Hello everyone!

    In Iroha, we were also trying to figure out a new way of translating our docs – we used POEditor before but it is so bad when it comes to automation. 
    Ry helped us with getting access to Transifex. I believe its best feature when comparing to manual translation is that the files can be easily updated automatically. Although I agree on your points for sure, it is a tricky tool. 
    Anyway, we might be writing some sort of a script anyway to compare the current docs with translations at some point – maybe we could combine our efforts somehow? We do not have much resources right now but still. Let's connect and share ideas! 

    Sara Garifullina,
    Community manager at Soramitsu
    Contact me: garifullina@...



    On Fri, Jan 17, 2020 at 7:07 AM Brian Behlendorf <bbehlendorf@...> wrote:
    This has gone without a reply since it was posted so I thought I would add one,

    It's terrific to see this energy for expanding the global footprint for Fabric! And for taking such a well researched and thoughtful approach to figuring out how to support the needs of translators efficiently. And your recommendations on bold at the bottom make sense for me. Thank you for writing up the recommendations and the rationale, that is valuable for future teams looking at this. An additional repo makes a ton of sense. I am sure here are good techniques to correlate updates to core docs to a need for updating their translated equivalents.

    So far, the TSC seems like it has been happy leaving these questions up to individual projects rather than setting a site-wide standard. But the TSC and others in the community might still want to weigh in on this, and if it looks good, consider adopting it as a common standard across projects, so that it's even easier for volunteers for translations on any project to know how and where to plug in.

    One last question: would it make sense for translation bundles for in-app localizations to be done in this -i18n repo, or to be done in the main code repo? I'm guessing the former so that a distribution can easily bundle them all together, and they change much less frequently, but I believe they are as important as translated docs (for projects that use them) to highlight to volunteers.

    Again, thanks!

    Brian

    On January 13, 2020 2:57:48 PM GMT+08:00, Yang Cheng <great_cy_ang@...> wrote:
    Dear Hyperledger community,

    We are a small group of volunteers that have been translating Fabric docs to Chinese since 2018. We’d like to share our current status and rationale behinds some decisions for your reference.

    Tool selection

    We initially started off using github, since it’s familiar to most of developers, and other projects like k8s have been doing the same. The workflow roughly looks like this:

    Admins:
    1.create branches in `hyperledger-labs/fabric-docs-cn` following Fabric release tags, for example `1.4.2_zh-CN`
    2.populated Github issues with untranslated docs
    3.assign issues to translators upon request
    4.review pull request
    5.readthedocs is updated automatically upon successful merge
    6.periodically pull in updates from Fabric docs in the form of new issues

    Translators:
    1.browse Github issues looking for unassigned issues
    2.assign issue by commenting on it
    3.translate and submit pull request

    This workflow had served us well for a small group of contributors. Later on, translation tools, in particular Zanata and Transifex, were proposed by community members, and we decided to give them a try. However, several major drawbacks of Transifex were observed after months of trial:

    1.slow access in this region, resulting in bad user experience
    2.intermediate files (.po) loses annotations during conversion, resulting in bad formats
    3.no commit sign-off when eventually pushed to github

    Therefore, we went back to Github. However, this does not mean we rule out the option of using professional tool, which obviously has its own advantages. Our current focus is to get things done and keep handful of contributors happy. When the time comes that Github becomes bottleneck (either due to increase of volunteers, or number of languages being translated to), we are definitely open for reassessment of tooling.

    Location of translated docs

    It was proposed to separate docs from Fabric code repo, which can co-exist with translations, similar to k8s [1]. Although the proposal was turned down for solid reasons, and we are happily informed that readthedocs actually supports multiple Github repo setup [2]. This is so far the least invasive option to incorporate non-English docs into main site.

    We do not think putting translated docs into Fabric core repo is a good idea, even with fine-grained maintainer-ship in place. The PR page would be overwhelmed by foreign characters and we are no longer able to track tasks with Github issues. Besides, it doesn’t really buy us anything beyond one less repo.

    To avoid creating new repo for each language that people are interested in translation, we could also setup a repo `Fabric-i18n` containing them as separate directories, e.g. `zh`, `es`, `de`, etc.

    This is how things get done today and we definitely welcome any suggestion and feedback. As the number of volunteers and languages grow, we believe a standardized process will emerge.

    Thank you,
    Cheng Yang

    [2] here’s a demonstration website to show how to incorporate multiple github repo into one readthedocs site https://stone-fabric.readthedocs.io/zh/release-1.4_zh-cn/

    --
    程阳
    Yang Cheng

    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    Re: [Hyperledger Fabric] [Hyperledger Technical WG China] [i18n] Status report on translation of Fabric docs

    Yang Cheng
     

    Hi, Brain, 

    Thanks for your replay, for now our translating work is mainly for fabric project and Chinese language, and just a dozen translators, so that the workflow is good for us now. We are also looking for a way adopting different projects and manage the updates conveniently, because we also want to translate the docs of other projects like Indy. We have learned the workflow of kubernetes, they also use github for translating jobs, they made scripts to generate github issues automatically, and developed a slack robot to manage the issues. We want to use the same workflow, but Fabric is different with kubernetes, the docs are separated from code repo and showed in a website they developed, not readthedocs. So we have to find other ways and tools, maybe we also have to develop some tools for this job. We will not use Transifex because it is really inefficient for us, translate with text editor and manage the translations with github is more efficient, we will keeping using github for translating until find a better way. 


    Now, what we want is :

    1. Show the Chinese translations in the official docs page, so that more developers would see the translations, and may attract more translators.

    2. Create a new repo in github named “fabric-i18n” or “hyperledger-i18n”, so we can put the docs of different projects into the same repo, like sdk, fabric-ca, Indy projects not only Fabric.


    About in-app localization, we won’t do it right now, it is much complex we should change many codes in Fabric, and actually most developers are used to English output, so the translation is not necessary now.

     

    Yours,

    Cheng Yang



    --
    程阳
    Yang Cheng
    great_cy_ang@...

    At 2020-01-17 12:07:40, "Brian Behlendorf" <bbehlendorf@...> wrote:

    This has gone without a reply since it was posted so I thought I would add one,

    It's terrific to see this energy for expanding the global footprint for Fabric! And for taking such a well researched and thoughtful approach to figuring out how to support the needs of translators efficiently. And your recommendations on bold at the bottom make sense for me. Thank you for writing up the recommendations and the rationale, that is valuable for future teams looking at this. An additional repo makes a ton of sense. I am sure here are good techniques to correlate updates to core docs to a need for updating their translated equivalents.

    So far, the TSC seems like it has been happy leaving these questions up to individual projects rather than setting a site-wide standard. But the TSC and others in the community might still want to weigh in on this, and if it looks good, consider adopting it as a common standard across projects, so that it's even easier for volunteers for translations on any project to know how and where to plug in.

    One last question: would it make sense for translation bundles for in-app localizations to be done in this -i18n repo, or to be done in the main code repo? I'm guessing the former so that a distribution can easily bundle them all together, and they change much less frequently, but I believe they are as important as translated docs (for projects that use them) to highlight to volunteers.

    Again, thanks!

    Brian

    On January 13, 2020 2:57:48 PM GMT+08:00, Yang Cheng <great_cy_ang@...> wrote:
    Dear Hyperledger community,

    We are a small group of volunteers that have been translating Fabric docs to Chinese since 2018. We’d like to share our current status and rationale behinds some decisions for your reference.

    Tool selection

    We initially started off using github, since it’s familiar to most of developers, and other projects like k8s have been doing the same. The workflow roughly looks like this:

    Admins:
    1.create branches in `hyperledger-labs/fabric-docs-cn` following Fabric release tags, for example `1.4.2_zh-CN`
    2.populated Github issues with untranslated docs
    3.assign issues to translators upon request
    4.review pull request
    5.readthedocs is updated automatically upon successful merge
    6.periodically pull in updates from Fabric docs in the form of new issues

    Translators:
    1.browse Github issues looking for unassigned issues
    2.assign issue by commenting on it
    3.translate and submit pull request

    This workflow had served us well for a small group of contributors. Later on, translation tools, in particular Zanata and Transifex, were proposed by community members, and we decided to give them a try. However, several major drawbacks of Transifex were observed after months of trial:

    1.slow access in this region, resulting in bad user experience
    2.intermediate files (.po) loses annotations during conversion, resulting in bad formats
    3.no commit sign-off when eventually pushed to github

    Therefore, we went back to Github. However, this does not mean we rule out the option of using professional tool, which obviously has its own advantages. Our current focus is to get things done and keep handful of contributors happy. When the time comes that Github becomes bottleneck (either due to increase of volunteers, or number of languages being translated to), we are definitely open for reassessment of tooling.

    Location of translated docs

    It was proposed to separate docs from Fabric code repo, which can co-exist with translations, similar to k8s [1]. Although the proposal was turned down for solid reasons, and we are happily informed that readthedocs actually supports multiple Github repo setup [2]. This is so far the least invasive option to incorporate non-English docs into main site.

    We do not think putting translated docs into Fabric core repo is a good idea, even with fine-grained maintainer-ship in place. The PR page would be overwhelmed by foreign characters and we are no longer able to track tasks with Github issues. Besides, it doesn’t really buy us anything beyond one less repo.

    To avoid creating new repo for each language that people are interested in translation, we could also setup a repo `Fabric-i18n` containing them as separate directories, e.g. `zh`, `es`, `de`, etc.

    This is how things get done today and we definitely welcome any suggestion and feedback. As the number of volunteers and languages grow, we believe a standardized process will emerge.

    Thank you,
    Cheng Yang

    [2] here’s a demonstration website to show how to incorporate multiple github repo into one readthedocs site https://stone-fabric.readthedocs.io/zh/release-1.4_zh-cn/

    --
    程阳
    Yang Cheng
    great_cy_ang@...

    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    Re: [i18n] Status report on translation of Fabric docs

    sankarshan
     

    On Mon, 13 Jan 2020 at 12:28, Yang Cheng <great_cy_ang@...> wrote:

    Dear Hyperledger community,

    We are a small group of volunteers that have been translating Fabric docs to Chinese since 2018. We’d like to share our current status and rationale behinds some decisions for your reference.

    Tool selection

    We initially started off using github, since it’s familiar to most of developers, and other projects like k8s have been doing the same. The workflow roughly looks like this:

    Admins:

    1.create branches in `hyperledger-labs/fabric-docs-cn` following Fabric release tags, for example `1.4.2_zh-CN`
    2.populated Github issues with untranslated docs
    3.assign issues to translators upon request
    4.review pull request
    5.readthedocs is updated automatically upon successful merge
    6.periodically pull in updates from Fabric docs in the form of new issues

    Translators:

    1.browse Github issues looking for unassigned issues
    2.assign issue by commenting on it
    3.translate and submit pull request
    Thank you for sharing the workflow. As someone who has in the past
    contributed to i18n for Indian languages, I can relate to how this
    makes it easy for a well knit group to focus on the work.

    This workflow had served us well for a small group of contributors. Later on, translation tools, in particular Zanata and Transifex, were proposed by community members, and we decided to give them a try. However, several major drawbacks of Transifex were observed after months of trial:

    1.slow access in this region, resulting in bad user experience
    2.intermediate files (.po) loses annotations during conversion, resulting in bad formats
    3.no commit sign-off when eventually pushed to github

    Therefore, we went back to Github. However, this does not mean we rule out the option of using professional tool, which obviously has its own advantages. Our current focus is to get things done and keep handful of contributors happy. When the time comes that Github becomes bottleneck (either due to increase of volunteers, or number of languages being translated to), we are definitely open for reassessment of tooling.
    I am not sure if the Zanata system continues to have sufficient
    development effort behind it. I am aware that Openstack is one of the
    large early adopters and continue to use it for handling i18n
    workflows.


    Re: [Hyperledger Technical WG China] [i18n] Status report on translation of Fabric docs

    Sara Garifullina <garifullina@...>
     

    Hello everyone!

    In Iroha, we were also trying to figure out a new way of translating our docs – we used POEditor before but it is so bad when it comes to automation. 
    Ry helped us with getting access to Transifex. I believe its best feature when comparing to manual translation is that the files can be easily updated automatically. Although I agree on your points for sure, it is a tricky tool. 
    Anyway, we might be writing some sort of a script anyway to compare the current docs with translations at some point – maybe we could combine our efforts somehow? We do not have much resources right now but still. Let's connect and share ideas! 

    Sara Garifullina,
    Community manager at Soramitsu
    Contact me: garifullina@...



    On Fri, Jan 17, 2020 at 7:07 AM Brian Behlendorf <bbehlendorf@...> wrote:
    This has gone without a reply since it was posted so I thought I would add one,

    It's terrific to see this energy for expanding the global footprint for Fabric! And for taking such a well researched and thoughtful approach to figuring out how to support the needs of translators efficiently. And your recommendations on bold at the bottom make sense for me. Thank you for writing up the recommendations and the rationale, that is valuable for future teams looking at this. An additional repo makes a ton of sense. I am sure here are good techniques to correlate updates to core docs to a need for updating their translated equivalents.

    So far, the TSC seems like it has been happy leaving these questions up to individual projects rather than setting a site-wide standard. But the TSC and others in the community might still want to weigh in on this, and if it looks good, consider adopting it as a common standard across projects, so that it's even easier for volunteers for translations on any project to know how and where to plug in.

    One last question: would it make sense for translation bundles for in-app localizations to be done in this -i18n repo, or to be done in the main code repo? I'm guessing the former so that a distribution can easily bundle them all together, and they change much less frequently, but I believe they are as important as translated docs (for projects that use them) to highlight to volunteers.

    Again, thanks!

    Brian

    On January 13, 2020 2:57:48 PM GMT+08:00, Yang Cheng <great_cy_ang@...> wrote:
    Dear Hyperledger community,

    We are a small group of volunteers that have been translating Fabric docs to Chinese since 2018. We’d like to share our current status and rationale behinds some decisions for your reference.

    Tool selection

    We initially started off using github, since it’s familiar to most of developers, and other projects like k8s have been doing the same. The workflow roughly looks like this:

    Admins:
    1.create branches in `hyperledger-labs/fabric-docs-cn` following Fabric release tags, for example `1.4.2_zh-CN`
    2.populated Github issues with untranslated docs
    3.assign issues to translators upon request
    4.review pull request
    5.readthedocs is updated automatically upon successful merge
    6.periodically pull in updates from Fabric docs in the form of new issues

    Translators:
    1.browse Github issues looking for unassigned issues
    2.assign issue by commenting on it
    3.translate and submit pull request

    This workflow had served us well for a small group of contributors. Later on, translation tools, in particular Zanata and Transifex, were proposed by community members, and we decided to give them a try. However, several major drawbacks of Transifex were observed after months of trial:

    1.slow access in this region, resulting in bad user experience
    2.intermediate files (.po) loses annotations during conversion, resulting in bad formats
    3.no commit sign-off when eventually pushed to github

    Therefore, we went back to Github. However, this does not mean we rule out the option of using professional tool, which obviously has its own advantages. Our current focus is to get things done and keep handful of contributors happy. When the time comes that Github becomes bottleneck (either due to increase of volunteers, or number of languages being translated to), we are definitely open for reassessment of tooling.

    Location of translated docs

    It was proposed to separate docs from Fabric code repo, which can co-exist with translations, similar to k8s [1]. Although the proposal was turned down for solid reasons, and we are happily informed that readthedocs actually supports multiple Github repo setup [2]. This is so far the least invasive option to incorporate non-English docs into main site.

    We do not think putting translated docs into Fabric core repo is a good idea, even with fine-grained maintainer-ship in place. The PR page would be overwhelmed by foreign characters and we are no longer able to track tasks with Github issues. Besides, it doesn’t really buy us anything beyond one less repo.

    To avoid creating new repo for each language that people are interested in translation, we could also setup a repo `Fabric-i18n` containing them as separate directories, e.g. `zh`, `es`, `de`, etc.

    This is how things get done today and we definitely welcome any suggestion and feedback. As the number of volunteers and languages grow, we believe a standardized process will emerge.

    Thank you,
    Cheng Yang

    [2] here’s a demonstration website to show how to incorporate multiple github repo into one readthedocs site https://stone-fabric.readthedocs.io/zh/release-1.4_zh-cn/

    --
    程阳
    Yang Cheng

    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.


    Identity Working Group zoom call Wednesday Jan 22, 2020 12 noon EST

    Vipin Bharathan
     

    Hi all,

    Announcing a call of the ID WG
    When:
    Wednesday Jan 22, 2020 12 noon EST (1700 UTC)
    Where:
    Call is on hyperledger zoom.

    Main events: 
    The full Agenda is available here:

    Select Items from the Agenda:
    • Privacy laws and Identity Blockchain implications.
      • Privacy laws across the world with aside on state laws of US- Vipin Bharathan
      • Kalyan Kulkarni & Ajay Jadhav Privacy laws in India: new ruling. PDP
    • A talk by Kim Cameron .- Feb 5th
    • Future talks:
      • Guardianship - a Sovrin whitepaper
      • Identity for IOT- Blockchain implications Bhawana Singh, JNU 
    Your ideas for 2020 for the Identity WG are always welcome.

    This is an open call, where all are welcome!
    We continue interesting talks laid out for the next few months, always topical- focused on hard problems in Digital Identity & the Blockchain with a focus on Hyperledger.
    Let us have some fun!

    Best,
    Vipin


    In Memoriam, Tamas Blummer

    Vipin Bharathan
     

    Hi all,

    Tamas Blummer, former member of Hyperledger TSC passed away on Jan 12, 2020. He had been battling cancer for the last couple of years.
    Tamas was elected to the TSC following the dissolution of the first genesis TSC, which was nominated by the charter members.
    Tamas was the first person I met, when I came to the first ever Hyperledger hackathon in JPM Chase in Metrotech, Brooklyn. This was back in March 2016. We met in the elevator, as we were riding up and we immediately felt comfortable with each other as we had similar backgrounds in financial infrastructure, and I sat with his team during the hackathon.
    Later, I was to learn that Tamas had started working on the Bitcoin core back in 2012. His interest in Bitcoin continued as he was working on RustBitcoin till almost the very end, his last commit was on Jan 2nd, 2020.
    Tamas was the chief ledger architect in Digital Asset Holdings at that time. I still remember his measured voice and technical presentations both during the hackathon and the TSC meetings.
    I will miss him.

    In sorrow,
    Vipin


    Re: DCO topic

    Brian Behlendorf
     


    I like the idea, I think.  I've forwarded it along to LF Legal for comment.  I would caution against any solution that requires work on LF's product department, it's undermanned and working on purging a lot of technical debt at the moment, but this is in line with what the LF wants LFID to be used for, so it may get priority.  If there are ways to accomplish this with minimal or nil product changes then that would be great.  But let's see if LF Legal sees some holes in this.

    Brian

    On 1/16/20 10:39 AM, Montgomery, Hart wrote:

    Hi Everyone,

     

    Thanks for the informative responses.  I’m with Chris here—it might be time to consider a CLA model.  I highly doubt the board will let us keep doing what we’ve done so far after they look into this.

     

    I think we could also do this pseudonymously.  Consider the following model:  the root of all identity in Hyperledger is the LFID.  We attach a CLA, email, real name (or whatever identity information we want) to an LFID.  We also require people to list their github accounts in their LFID info.  However, all of this information is kept private, so no one (other than the LF database) sees anything at all.  We set permissions on HL github repos so that only github accounts that are associated with an LFID in good standing can commit code.

     

    I don’t know enough about the current LFID infrastructure to know whether this is possible (or how much work it would take to make it possible) but this would give us seemingly “best possible” anonymity.  The LF would know who the contributors are, but everything public-facing could be anonymous.  You could configure your github account, which is what the public would see, to be totally anonymizing.  You could even add multiple github accounts to your LFID if you really wanted to confuse people, although I don’t know if anyone would do this.  I think this would address the concerns of most of the people who were interested in anonymity that I spoke to on this:  they didn’t seem to care as much if the LF knew who they were as much as they wanted to avoid random people on the internet being able to find or contact them.

     

    This would also have the side benefit of making community statistics easy to gather since the LF would have the relevant information about people (we could, of course, use differentially private techniques to release information about contributors).  In addition, it would address a lot of concerns people have addressed with TSC elections, since we could use the LFID for that too.

     

    What do folks think about something like this?

     

    Thanks a lot for your time, and have a great day.

     

    Hart

     

    From: tsc@... [mailto:tsc@...] On Behalf Of Christopher Ferris
    Sent: Thursday, January 16, 2020 9:24 AM
    To: bbehlendorf@...
    Cc: Montgomery, Hart <hmontgomery@...>; Arnaud Le Hors <lehors@...>; tsc@...
    Subject: Re: [Hyperledger TSC] DCO topic

     

    Fabric, having moved from Gerrit (which required a LF ID) to GitHub (which does not) now opens up a bit of risk unless the maintainers reviewing patches also know who the submitter is. With Linux Kernel, all patches are submitted via email, so the address is resolvable by definition. While we do know the GitHub account from whence a PR is submitted, a GitHub ID does not require any form of further identification (name, email, etc) I have seen patches submitted with emails of the form: somebody@.... Where 'somebody' is the Git Hub id.

     

    The purpose of the DCO was to reduce friction, not to allow anonymous contribution. Getting a CLA signed off for a corporate employee can be torturous because you might need to involve your Legal department, etc.

     

    Should we (TSC) maybe be thinking of making a recommendation of adopting a CLA model instead, despite the friction? There are now tools in place to automate this.

     

    Cheers,

    Christopher Ferris
    IBM Fellow, CTO Open Technology
    email: chrisfer@...
    twitter: @christo4ferris

    IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
    phone: +1 508 667 0402

     

     

    ----- Original message -----
    From: "Brian Behlendorf" <bbehlendorf@...>
    Sent by: tsc@...
    To: Arnaud Le Hors <lehors@...>, "hmontgomery@..." <hmontgomery@...>
    Cc: "tsc@..." <tsc@...>
    Subject: [EXTERNAL] [Hyperledger TSC] DCO topic
    Date: Thu, Jan 16, 2020 8:41 AM
     

    LF legal looked at the item and were wondering what underlying need was motivating the ask.  "In the Linux kernel for example the maintainers are expected to know the identity of anyone whose patches they're contributing. The real issue is if there was ever a legal matter, would the person be identifiable and available because we have their identity."  I was going to bring that question back to here but fell behind. 

     

    The risk of taking a DCO from someone that can't be identified and reached is that a challenge to the provenance of that code can't be answered - basically anyone could claim "that was mine, you accepted stolen property" and there'd be no one to refute that or take the blame for it.  In which case there'd be a very difficult decision - fight in court without any testimony that the code wasn't stolen, or purge the code and require a clean-room rewrite.  Those seem like awful paths to have to take, for the price of more vigilance up front.

     

    Given this is a matter of legal liability, it's not a decision the TSC can make; at best it could recommend a change to the Governing Board and LF, but it's the GB and LF that need to weigh that risk as they're the ones who would bear the costs of any legal action.

     

    I wasn't on Hyperledger on day zero, but one thing I recall hearing is that one reason it was formed was to provide a space safe from anonymous contributors who may come along later seeking rent.  I remember specifically hearing that if it turned out Craig Wright was Satoshi, then the Australian patents he (much later) filed on Bitcoin architecture could be leveraged against anyone in the Bitcoin community, in part because the license on the code was MIT and thus came with no patent grants.  I think we want to avoid that risk.  

     

    However I know the term "real identity" is highly problematic.  We aren't storing Social Security numbers or DNA or anything like that.  The DCO is attached to the commit or PR, from which we can get the Github account name, but that doesn't necessarily come with a real name or even a contactable email address, which is also a problem when we pull together the voter lists for the TSC election.  Are each of you sure you'd be able to get in contact with all submitters of PRs you've accepted?  Even good, real people have their email addresses go bad or name changes and then can't be reached.  So this isn't about providing a hermetic seal around the problem, more showing good faith and intent in ensuring we don't receive stolen or patent-covered code.

     

    I'll try and get more clarity.  Til then, please document any instances where people refuse to offer PRs because they don't want to be contactable after the fact.

     

    Brian

     

     

     

     

    On 1/16/20 3:53 AM, Arnaud Le Hors wrote:

    Thanks for the reminder Hart. Brian was going to bring this up to LF legal. Brian, any update?
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





    From:        "hmontgomery@..." <hmontgomery@...>
    To:        Arnaud Le Hors <lehors@...>, Christopher Ferris <chrisfer@...>, Silona Bonewald <sbonewald@...>
    Cc:        "dan.middleton@..." <dan.middleton@...>, "mwagner114@..." <mwagner114@...>, "tsc@..." <tsc@...>
    Date:        01/16/2020 02:42 AM
    Subject:        [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Sent by:        tsc@...


     

    Hi Everyone,

     

    Thanks for all the emails, and it’s great to hear from you all post-winter holidays.

     

    I had a question:  has any progress been made on the DCO front?  An email update would be awesome if there has been any news.

     

    Thanks a lot for your time, and have a great day.

     

    Thanks,

    Hart

     

    From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
    Sent: Wednesday, January 15, 2020 10:51 AM
    To: Christopher Ferris <chrisfer@...>; Silona Bonewald <sbonewald@...>
    Cc: dan.middleton@...; mwagner114@...; tsc@...
    Subject: Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16

     

    All right, let's cancel the call this week again but, please, let's make sure we make progress for next week.

    Chris, I will take over the issue on promoted release, so you can focus on trying to make progress on the repo structure.
    Silona, please, try to put together a proposal for the governing doc update Task Force.


    Thanks.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





    From:        "Christopher Ferris" <chrisfer@...>
    To:        mwagner114@...
    Cc:        dan.middleton@..., "Arnaud Le Hors" <lehors@...>, tsc@...
    Date:        01/15/2020 07:27 PM
    Subject:        [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Sent by:        tsc@...





    Yeah, I've been tied up in an offsite and haven't been able to make any progress on my actions (including the Fabric report). Apologies.

    Cheers,

    Christopher Ferris
    IBM Fellow, CTO Open Technology
    email:
    chrisfer@...
    twitter: @christo4ferris
    blog:
    https://developer.ibm.com/code/author/chrisfer/
    IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
    phone: +1 508 667 0402


    ----- Original message -----
    From: "Mark Wagner" <mwagner114@...>
    Sent by: tsc@...
    To: Arnaud Le Hors <lehors@...>
    Cc: "Middleton, Dan" <dan.middleton@...>, "Technical Steering Committee (TSC)" <tsc@...>
    Subject: [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Date: Wed, Jan 15, 2020 1:14 PM

    so no meeting?
     
    On Wed, Jan 15, 2020, 08:23 Arnaud Le Hors <lehors@...> wrote:
    Thanks Dan for your input.

    The thing is that we do have owners for the open issues. Chris is leading the repo structure TF, and volunteered to make a clean proposal on the promoted release one. Silona owns the TF proposal one for governing docs. Evidently they just haven't had a chance to make progress on these.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





    From:        "Middleton, Dan" <dan.middleton@...>
    To:        Arnaud Le Hors <lehors@...>, "Technical Steering Committee (TSC)" <tsc@...>
    Date:        01/15/2020 09:20 AM
    Subject:        [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Sent by:        tsc@...


     

    I have added a couple DCI announcements, but these announcements do not warrant a meeting.

    • DCI:
      • The DCI survey has incorporated edits from the fall review. HL marketing suggests it launch ahead of the Davos marketing campaign so we can make use of visibility from those hyperledger activities. This window also lets us assemble results in time to share at HLGF.
      • HL is requesting mentors for HLGF for a speed mentoring session. Details of the session are being planned. Please contact Celia Stamps <cstamps@linuxfoundation.org> if you would like to volunteer as a mentor.

    I think it would be ideal to identify / remind owners for/of the open tasks this week and we all commit to meeting next week with some progress achieved. This is not a full list of open items but a couple items I see after reviewing our last few meeting minutes…

    • Repo structure task force:
    • Cleaning up / reorganizing the governing documents.
      • I believe we need a task force proposal?

     

    Regards,
    Dan

     

    From: <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
    Date: Wednesday, January 15, 2020 at 8:40 AM
    To: "Technical Steering Committee (TSC)" <
    tsc@...>
    Subject: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16

     

    Hi all,
    I'd rather not cancel this week's call but I can't say that I've seen much evidence of progress on the open issues. So, I'm hereby inviting everyone to chime in on what the agenda should cover this week.

    The draft is here:
    https://wiki.hyperledger.org/display/TSC/2020-01-16+TSC+Agenda

    Short of being able to build a decent agenda I will cancel (again).

    Thanks.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM



     






     




     

     

    --
    Brian Behlendorf
    Executive Director, Hyperledger
    bbehlendorf@...
    Twitter: @brianbehlendorf

     

     


    -- 
    Brian Behlendorf
    Executive Director, Hyperledger
    bbehlendorf@...
    Twitter: @brianbehlendorf


    Re: DCO topic

    bill
     

    Perhaps a MOSS; Measure of Software Similarity system would work.  Some open source available although they may need a good bit of additional languages added, etc.  Many paid platforms available. Perhaps the HL list can query alma mater’s and employers to see who is using what.  Many CS departments using to check exams/assignments and employers screening applicant programming work.  Just a very cursory look below. Github is screened heavily.

     

    https://warwick.ac.uk/fac/sci/dcs/research/ias/software/sherlock/  seems to be current, in use and being maintained.

     

    http://theory.stanford.edu/~aiken/moss/  Stanford does use the program even for some online courses.

     

    https://github.com/arthurzaczek/OSPC  last update 2 years ago but maybe a decent start

     

    https://github.com/danainschool/moss-taps  at least 4 years old. Would require work to pull down and adapt.

     

    Cheers,

     

    B

     

     

     

    From: tsc@... <tsc@...> On Behalf Of Christopher Ferris
    Sent: Thursday, January 16, 2020 11:24 AM
    To: bbehlendorf@...
    Cc: hmontgomery@...; Arnaud Le Hors <lehors@...>; tsc@...
    Subject: Re: [Hyperledger TSC] DCO topic

     

    Fabric, having moved from Gerrit (which required a LF ID) to GitHub (which does not) now opens up a bit of risk unless the maintainers reviewing patches also know who the submitter is. With Linux Kernel, all patches are submitted via email, so the address is resolvable by definition. While we do know the GitHub account from whence a PR is submitted, a GitHub ID does not require any form of further identification (name, email, etc) I have seen patches submitted with emails of the form: somebody@.... Where 'somebody' is the Git Hub id.

     

    The purpose of the DCO was to reduce friction, not to allow anonymous contribution. Getting a CLA signed off for a corporate employee can be torturous because you might need to involve your Legal department, etc.

     

    Should we (TSC) maybe be thinking of making a recommendation of adopting a CLA model instead, despite the friction? There are now tools in place to automate this.

     

    Cheers,

    Christopher Ferris
    IBM Fellow, CTO Open Technology
    email: chrisfer@...
    twitter: @christo4ferris

    IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
    phone: +1 508 667 0402

     

     

    ----- Original message -----
    From: "Brian Behlendorf" <bbehlendorf@...>
    Sent by: tsc@...
    To: Arnaud Le Hors <lehors@...>, "hmontgomery@..." <hmontgomery@...>
    Cc: "tsc@..." <tsc@...>
    Subject: [EXTERNAL] [Hyperledger TSC] DCO topic
    Date: Thu, Jan 16, 2020 8:41 AM
     

    LF legal looked at the item and were wondering what underlying need was motivating the ask.  "In the Linux kernel for example the maintainers are expected to know the identity of anyone whose patches they're contributing. The real issue is if there was ever a legal matter, would the person be identifiable and available because we have their identity."  I was going to bring that question back to here but fell behind. 

     

    The risk of taking a DCO from someone that can't be identified and reached is that a challenge to the provenance of that code can't be answered - basically anyone could claim "that was mine, you accepted stolen property" and there'd be no one to refute that or take the blame for it.  In which case there'd be a very difficult decision - fight in court without any testimony that the code wasn't stolen, or purge the code and require a clean-room rewrite.  Those seem like awful paths to have to take, for the price of more vigilance up front.

     

    Given this is a matter of legal liability, it's not a decision the TSC can make; at best it could recommend a change to the Governing Board and LF, but it's the GB and LF that need to weigh that risk as they're the ones who would bear the costs of any legal action.

     

    I wasn't on Hyperledger on day zero, but one thing I recall hearing is that one reason it was formed was to provide a space safe from anonymous contributors who may come along later seeking rent.  I remember specifically hearing that if it turned out Craig Wright was Satoshi, then the Australian patents he (much later) filed on Bitcoin architecture could be leveraged against anyone in the Bitcoin community, in part because the license on the code was MIT and thus came with no patent grants.  I think we want to avoid that risk.  

     

    However I know the term "real identity" is highly problematic.  We aren't storing Social Security numbers or DNA or anything like that.  The DCO is attached to the commit or PR, from which we can get the Github account name, but that doesn't necessarily come with a real name or even a contactable email address, which is also a problem when we pull together the voter lists for the TSC election.  Are each of you sure you'd be able to get in contact with all submitters of PRs you've accepted?  Even good, real people have their email addresses go bad or name changes and then can't be reached.  So this isn't about providing a hermetic seal around the problem, more showing good faith and intent in ensuring we don't receive stolen or patent-covered code.

     

    I'll try and get more clarity.  Til then, please document any instances where people refuse to offer PRs because they don't want to be contactable after the fact.

     

    Brian

     

     

     

     

    On 1/16/20 3:53 AM, Arnaud Le Hors wrote:

    Thanks for the reminder Hart. Brian was going to bring this up to LF legal. Brian, any update?
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





    From:        "hmontgomery@..." <hmontgomery@...>
    To:        Arnaud Le Hors <lehors@...>, Christopher Ferris <chrisfer@...>, Silona Bonewald <sbonewald@...>
    Cc:        "dan.middleton@..." <dan.middleton@...>, "mwagner114@..." <mwagner114@...>, "tsc@..." <tsc@...>
    Date:        01/16/2020 02:42 AM
    Subject:        [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Sent by:        tsc@...


     

    Hi Everyone,

     

    Thanks for all the emails, and it’s great to hear from you all post-winter holidays.

     

    I had a question:  has any progress been made on the DCO front?  An email update would be awesome if there has been any news.

     

    Thanks a lot for your time, and have a great day.

     

    Thanks,

    Hart

     

    From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
    Sent: Wednesday, January 15, 2020 10:51 AM
    To: Christopher Ferris <chrisfer@...>; Silona Bonewald <sbonewald@...>
    Cc: dan.middleton@...; mwagner114@...; tsc@...
    Subject: Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16

     

    All right, let's cancel the call this week again but, please, let's make sure we make progress for next week.

    Chris, I will take over the issue on promoted release, so you can focus on trying to make progress on the repo structure.
    Silona, please, try to put together a proposal for the governing doc update Task Force.


    Thanks.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





    From:        "Christopher Ferris" <chrisfer@...>
    To:        mwagner114@...
    Cc:        dan.middleton@..., "Arnaud Le Hors" <lehors@...>, tsc@...
    Date:        01/15/2020 07:27 PM
    Subject:        [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Sent by:        tsc@...





    Yeah, I've been tied up in an offsite and haven't been able to make any progress on my actions (including the Fabric report). Apologies.

    Cheers,

    Christopher Ferris
    IBM Fellow, CTO Open Technology
    email:
    chrisfer@...
    twitter: @christo4ferris
    blog:
    https://developer.ibm.com/code/author/chrisfer/
    IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
    phone: +1 508 667 0402


    ----- Original message -----
    From: "Mark Wagner" <mwagner114@...>
    Sent by: tsc@...
    To: Arnaud Le Hors <lehors@...>
    Cc: "Middleton, Dan" <dan.middleton@...>, "Technical Steering Committee (TSC)" <tsc@...>
    Subject: [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Date: Wed, Jan 15, 2020 1:14 PM

    so no meeting?
     
    On Wed, Jan 15, 2020, 08:23 Arnaud Le Hors <lehors@...> wrote:
    Thanks Dan for your input.

    The thing is that we do have owners for the open issues. Chris is leading the repo structure TF, and volunteered to make a clean proposal on the promoted release one. Silona owns the TF proposal one for governing docs. Evidently they just haven't had a chance to make progress on these.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





    From:        "Middleton, Dan" <dan.middleton@...>
    To:        Arnaud Le Hors <lehors@...>, "Technical Steering Committee (TSC)" <tsc@...>
    Date:        01/15/2020 09:20 AM
    Subject:        [EXTERNAL] Re: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16
    Sent by:        tsc@...


     

    I have added a couple DCI announcements, but these announcements do not warrant a meeting.

    • DCI:
      • The DCI survey has incorporated edits from the fall review. HL marketing suggests it launch ahead of the Davos marketing campaign so we can make use of visibility from those hyperledger activities. This window also lets us assemble results in time to share at HLGF.
      • HL is requesting mentors for HLGF for a speed mentoring session. Details of the session are being planned. Please contact Celia Stamps <cstamps@linuxfoundation.org> if you would like to volunteer as a mentor.

    I think it would be ideal to identify / remind owners for/of the open tasks this week and we all commit to meeting next week with some progress achieved. This is not a full list of open items but a couple items I see after reviewing our last few meeting minutes…

    • Repo structure task force:
    • Cleaning up / reorganizing the governing documents.
      • I believe we need a task force proposal?

     

    Regards,
    Dan

     

    From: <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
    Date: Wednesday, January 15, 2020 at 8:40 AM
    To: "Technical Steering Committee (TSC)" <
    tsc@...>
    Subject: [Hyperledger TSC] Call for agenda items for TSC call of Jan 16

     

    Hi all,
    I'd rather not cancel this week's call but I can't say that I've seen much evidence of progress on the open issues. So, I'm hereby inviting everyone to chime in on what the agenda should cover this week.

    The draft is here:
    https://wiki.hyperledger.org/display/TSC/2020-01-16+TSC+Agenda

    Short of being able to build a decent agenda I will cancel (again).

    Thanks.
    --
    Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM



     






     




     

     

    --
    Brian Behlendorf
    Executive Director, Hyperledger
    bbehlendorf@...
    Twitter: @brianbehlendorf

     

     


    Re: [Hyperledger Technical WG China] [i18n] Status report on translation of Fabric docs

    Brian Behlendorf
     

    This has gone without a reply since it was posted so I thought I would add one,

    It's terrific to see this energy for expanding the global footprint for Fabric! And for taking such a well researched and thoughtful approach to figuring out how to support the needs of translators efficiently. And your recommendations on bold at the bottom make sense for me. Thank you for writing up the recommendations and the rationale, that is valuable for future teams looking at this. An additional repo makes a ton of sense. I am sure here are good techniques to correlate updates to core docs to a need for updating their translated equivalents.

    So far, the TSC seems like it has been happy leaving these questions up to individual projects rather than setting a site-wide standard. But the TSC and others in the community might still want to weigh in on this, and if it looks good, consider adopting it as a common standard across projects, so that it's even easier for volunteers for translations on any project to know how and where to plug in.

    One last question: would it make sense for translation bundles for in-app localizations to be done in this -i18n repo, or to be done in the main code repo? I'm guessing the former so that a distribution can easily bundle them all together, and they change much less frequently, but I believe they are as important as translated docs (for projects that use them) to highlight to volunteers.

    Again, thanks!

    Brian


    On January 13, 2020 2:57:48 PM GMT+08:00, Yang Cheng <great_cy_ang@...> wrote:
    Dear Hyperledger community,

    We are a small group of volunteers that have been translating Fabric docs to Chinese since 2018. We’d like to share our current status and rationale behinds some decisions for your reference.

    Tool selection

    We initially started off using github, since it’s familiar to most of developers, and other projects like k8s have been doing the same. The workflow roughly looks like this:

    Admins:
    1.create branches in `hyperledger-labs/fabric-docs-cn` following Fabric release tags, for example `1.4.2_zh-CN`
    2.populated Github issues with untranslated docs
    3.assign issues to translators upon request
    4.review pull request
    5.readthedocs is updated automatically upon successful merge
    6.periodically pull in updates from Fabric docs in the form of new issues

    Translators:
    1.browse Github issues looking for unassigned issues
    2.assign issue by commenting on it
    3.translate and submit pull request

    This workflow had served us well for a small group of contributors. Later on, translation tools, in particular Zanata and Transifex, were proposed by community members, and we decided to give them a try. However, several major drawbacks of Transifex were observed after months of trial:

    1.slow access in this region, resulting in bad user experience
    2.intermediate files (.po) loses annotations during conversion, resulting in bad formats
    3.no commit sign-off when eventually pushed to github

    Therefore, we went back to Github. However, this does not mean we rule out the option of using professional tool, which obviously has its own advantages. Our current focus is to get things done and keep handful of contributors happy. When the time comes that Github becomes bottleneck (either due to increase of volunteers, or number of languages being translated to), we are definitely open for reassessment of tooling.

    Location of translated docs

    It was proposed to separate docs from Fabric code repo, which can co-exist with translations, similar to k8s [1]. Although the proposal was turned down for solid reasons, and we are happily informed that readthedocs actually supports multiple Github repo setup [2]. This is so far the least invasive option to incorporate non-English docs into main site.

    We do not think putting translated docs into Fabric core repo is a good idea, even with fine-grained maintainer-ship in place. The PR page would be overwhelmed by foreign characters and we are no longer able to track tasks with Github issues. Besides, it doesn’t really buy us anything beyond one less repo.

    To avoid creating new repo for each language that people are interested in translation, we could also setup a repo `Fabric-i18n` containing them as separate directories, e.g. `zh`, `es`, `de`, etc.

    This is how things get done today and we definitely welcome any suggestion and feedback. As the number of volunteers and languages grow, we believe a standardized process will emerge.

    Thank you,
    Cheng Yang

    [2] here’s a demonstration website to show how to incorporate multiple github repo into one readthedocs site https://stone-fabric.readthedocs.io/zh/release-1.4_zh-cn/

    --
    程阳
    Yang Cheng
    great_cy_ang@...

    --
    Sent from my Android device with K-9 Mail. Please excuse my brevity.

    1061 - 1080 of 3898