Hello Jason, When we create certificates using cryptogen tool, for peer organizations, the user admin certificate has OU as "Admin", but in the case of Orderer Organization, Certificate has OU as

I’m glad to see doc is being a hot topic. Technical Working Group China(TWGC) has been working more than a year translating fabric doc into Chinese. There are more than 10 active volunteers who

I think that it is important not to conflate things. There's a request to add two maintainers who's role will be to help manage the Fabric documentation. I think that should be handled independent of

We could gate the DocBuild, UT and IT behind the success of VerifyBuild like we do today, and can set variables (BuildDoc and RunTests) as true or false and make them the conditions on which the

I have no clue in AZP, perhaps Brett canshed some light here, but - can't you just put in our scripts somethingthat does a git show --name-only and returns immediately in casethere are only changes to

Ok, we're getting closer. CODEOWNERS does indeed buy us some options. I think that would take us down to two remaining concerns with docs in Fabric repo. Anybody have ideas on solving these? 1) Doc

I too believe that the documentation belongs with the code. I also do not believe that every person who contributes should become a maintainer ... especially when they do not have a history of

I also feel that the 'default' position should be that docs reside with the code repo, and there would need to be a compelling reason to split them out. In my opinion given the recent changes, there

I agree that these would be two good additions to the docs maintainership. I approve. Chris

The SDK documentation and CA is only documentationabout APIs, it's not documentation about concepts, ideas, and tutorials. I don't think that extracting the fabricdocumentation files out of the fabric

For the record, I am not in favor of extracting the documentation. I strongly feel that the doc and the code should live together where feasible. My perspective is that lowering the barriers to

+1 for Jay's suggestion 发件人: fabric@... <fabric@...> 代表 Jay Guo <guojiannan1101@...> 发送时间: 2019年11月26日 22:11 收件人: Jay Guo <guojiannan1101@...> 抄送: David Enyeart

Just in case i wasn't stating my opinion clearly, i'd suggest to separate docs from code, and have multiple languages dirs within it, e.g. content |- en |- zh |- de - J

from translation point of view, i've seen some popular projects like k8s and tensorflow that separate docs from code, where i18n is first class citizen within the dir structure, for example [1] and

The intent of my proposal was exactly as Yacov says - doc maintainers would be comprised of the core Fabric maintainers in addition to heavy doc contributors/reviewers. I do understand Brian's point,

Something I forgot to mention, I'm also going investigate the use of a HSM. Maybe this could make things easier as apparently peers and orderers can connect to the HSM. If it enabled the retrieval of

Hi all, I would like to expose some ideas to have your feelings and ideas about the generation and sharing of the artifacts because I'm not sure about which path to take. In my network (deployed in

Hi Atsushi - Thanks for sharing your efforts to date. Overall, I like the idea of providing a utility to do this as generally we tell people that they can do this but don't provide any tools for

I think the best solution for these 2 seeminglyconflicting ideas is: All maintainers of code repositoriesshould be able to merge documentation contributions Maintainers of the documentation shouldnot

Thank you Pam. I'm very much in favour of these two nominations, and personally, I'd like to see more maintainers and contributors to Hyperledger Fabric in general, and documentation in particular. On