Wikis? (was Re: issues for fabric)


Brian Behlendorf <bbehlendorf@...>
 

For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@....

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric <hyperledger-fabric@...>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@... [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Binh Q Nguyen <binhn@...>
 

I don't have a preference, but we do have a need to relocate the Fabric wiki as it is no longer available.

Thanks,

- Binh

Brian Behlendorf ---08/08/2016 06:54:57 PM---For the time being we can continue using the Github wiki, but to make the migration complete we sho

From: Brian Behlendorf <bbehlendorf@...>
To: hyperledger-fabric@...
Date: 08/08/2016 06:54 PM
Subject: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Sent by: hyperledger-fabric-bounces@...





For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@....

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:
      Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.
      How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?
       
      Best Regards,
       
      Yuki Kondo
      Hitachi America, Ltd., Research & Development Division
      Tel: (408) 986-6460 | Mail: Yuki.Kondo@...
       

From: Christopher B Ferris [mailto:chrisfer@...]
Sent:
Monday, August 08, 2016 2:27 PM
To:
Kondo, Yuki
Cc:
hyperledger-fabric@...
Subject:
Re: [Hyperledger-fabric] issues for fabric
 
Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.
If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email:
chrisfer@...
twitter: @christo4ferris
blog:
https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 
 
----- Original message -----
From: "Kondo, Yuki"
<Yuki.Kondo@...>
Sent by:
hyperledger-fabric-bounces@...
To: hyperledger-fabric
<hyperledger-fabric@...>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@... [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent:
Monday, August 08, 2016 12:50 PM
To:
hyperledger-fabric
Subject:
Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email:
chrisfer@...

twitter: @christo4ferris

blog:
https://developer.ibm.com/opentech/author/chrisfer/

phone:
+1 508 667 0402




-----Ry Jones <
rjones@...> wrote: -----To: bob@...
From: Ry Jones <
rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <
hyperledger-fabric@...>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <
bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My
hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list

Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​
36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
 
 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric



Brian Behlendorf <bbehlendorf@...>
 

Correction: still visible, but not editable, which is just as bad.  Let's get input by the end of the week then.  I have also discovered we can add Confluence to the list of wiki software (Mediawiki, Dokuwiki) we can support.

Brian


On 08/08/2016 07:43 PM, Binh Q Nguyen wrote:

I don't have a preference, but we do have a need to relocate the Fabric wiki as it is no longer available.

Thanks,

- Binh

Brian Behlendorf ---08/08/2016 06:54:57 PM---For the time being we can continue using the Github wiki, but to make the migration complete we sho

From: Brian Behlendorf <bbehlendorf@...>
To: hyperledger-fabric@...
Date: 08/08/2016 06:54 PM
Subject: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Sent by: hyperledger-fabric-bounces@...





For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@....

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Gabor Hosszu
 

I had a look at the two Wikis (Media, Doku, http://www.wikimatrix.org/compare/dokuwiki+mediawiki and some example wikis), MediaWiki seems to be a little bit better, but I think the ultimate solution is really Confluence. As far as I know, it integrates with Jira and has some very good tools (gliffy plugin, etc).

On Tue, Aug 9, 2016 at 5:59 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Correction: still visible, but not editable, which is just as bad.  Let's get input by the end of the week then.  I have also discovered we can add Confluence to the list of wiki software (Mediawiki, Dokuwiki) we can support.

Brian



On 08/08/2016 07:43 PM, Binh Q Nguyen wrote:

I don't have a preference, but we do have a need to relocate the Fabric wiki as it is no longer available.

Thanks,

- Binh

Brian Behlendorf ---08/08/2016 06:54:57 PM---For the time being we can continue using the Github wiki, but to make the migration complete we sho

From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
To: hyperledger-fabric@lists.hyperledger.org
Date: 08/08/2016 06:54 PM
Subject: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org





For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--
GABOR HOSSZU

​DEVELOPER



+​36 1 883 0300 
​gabor
@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Shawn Amundson <amundson@...>
 


Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric



Baohua Yang
 

+1 on markdown!

traditional wiki grammar is too difficult for technical writing.

Maybe we can just make a special wiki sub project, and include all markdown files there, easy to read and update.

On Wed, Aug 10, 2016 at 6:13 AM, Shawn Amundson <amundson@...> wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--
Best wishes!

Baohua Yang


Brian Behlendorf <bbehlendorf@...>
 

Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian

On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@lists.hyperledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Christopher B Ferris <chrisfer@...>
 

+1

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

On Aug 9, 2016, at 6:13 PM, Shawn Amundson <amundson@...> wrote:


Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@lists.hyperledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.orghttps://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.orgTwitter: @brianbehlendorf

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




Shawn Amundson <amundson@...>
 

Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf


Brian Behlendorf <bbehlendorf@...>
 

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


jeremysevareid <jeremysevareid@...>
 

Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Brian Behlendorf <bbehlendorf@...>
 

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


jeremysevareid <jeremysevareid@...>
 

I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other? 

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc. 


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Brian Behlendorf <bbehlendorf@...>
 

On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


jeremysevareid <jeremysevareid@...>
 

Brian:

I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.

For the IP and attribution concerns,  does this apply to code only? Architecture white paper and requirements documents?

Jeremy


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Brian Behlendorf <bbehlendorf@...>
 

On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.

Willing to concede the point for now.

For the IP and attribution concerns,  does this apply to code only? Architecture white paper and requirements documents?

It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account.  I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs.

As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives.  That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. 

Here's an instance of Confluence running for another LF project, OPNFV: https://wiki.opnfv.org/

Note that they seem to use it for most of their community & web content.

Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires.

Brian


Jeremy


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Shawn Amundson <amundson@...>
 


About confluence...  Since it's not markdown or wiki syntax based, it is hard to pull information out.  It is also hard to paste text content into from terminal editors like vim (lots of time spent re-flowing line breaks).  Dokuwiki and mediawiki are open source and don't have those problems.  FWIW, when I've used dokuwiki in the past I've thought it was pretty nice/easy as far as wikis go.

Should we have an etherpad instance setup to fill the real-time collaboration need, as an alternative to google docs (for some subset of the google docs use case)?

-Shawn

On Tue, Aug 16, 2016 at 2:16 AM, Brian Behlendorf <bbehlendorf@...> wrote:
On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.

Willing to concede the point for now.

For the IP and attribution concerns,  does this apply to code only? Architecture white paper and requirements documents?

It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account.  I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs.

As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives.  That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. 

Here's an instance of Confluence running for another LF project, OPNFV: https://wiki.opnfv.org/

Note that they seem to use it for most of their community & web content.

Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires.

Brian



Jeremy


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...rg> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric



Brian Behlendorf <bbehlendorf@...>
 

So we're now not going with Confluence - I'm having a Dokuwiki instance set up with the markdown plugin installed.

Brian

On 08/16/2016 07:49 AM, Shawn Amundson wrote:

About confluence...  Since it's not markdown or wiki syntax based, it is hard to pull information out.  It is also hard to paste text content into from terminal editors like vim (lots of time spent re-flowing line breaks).  Dokuwiki and mediawiki are open source and don't have those problems.  FWIW, when I've used dokuwiki in the past I've thought it was pretty nice/easy as far as wikis go.

Should we have an etherpad instance setup to fill the real-time collaboration need, as an alternative to google docs (for some subset of the google docs use case)?

-Shawn

On Tue, Aug 16, 2016 at 2:16 AM, Brian Behlendorf <bbehlendorf@...> wrote:
On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.

Willing to concede the point for now.

For the IP and attribution concerns,  does this apply to code only? Architecture white paper and requirements documents?

It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account.  I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs.

As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives.  That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. 

Here's an instance of Confluence running for another LF project, OPNFV: https://wiki.opnfv.org/

Note that they seem to use it for most of their community & web content.

Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires.

Brian



Jeremy


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...rg> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@lists.hyperledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf


Jon Brisbin <jbrisbin@...>
 

We recently went through this discussion ourselves and decided that markdown or asciidoc (or both!) in GitHub was better because it automagically renders, you can link to anything you need using the built-in tools, it's searchable (hard to find good search in other wiki platforms), it's inherently source-controlled so changes to the docs are tracked, you can create PRs against the docs and review them before someone plops new content into the wiki and blasts whatever was there without much review, etc...

Just having a repo full of asciidoc would likely be sufficient. It wouldn't have to be processed into HTML and hosted. You could do that, of course, but IMO it's not really necessary since the default rendering of GitHub is sufficient for everything we need.

It beats maintaining a separate server just to run a wiki and then having to secure it, make sure it's up, keep it up to date, etc... Yuck.

jb

On Tue, Aug 23, 2016 at 11:24 PM Brian Behlendorf <bbehlendorf@...> wrote:
So we're now not going with Confluence - I'm having a Dokuwiki instance set up with the markdown plugin installed.

Brian

On 08/16/2016 07:49 AM, Shawn Amundson wrote:

About confluence...  Since it's not markdown or wiki syntax based, it is hard to pull information out.  It is also hard to paste text content into from terminal editors like vim (lots of time spent re-flowing line breaks).  Dokuwiki and mediawiki are open source and don't have those problems.  FWIW, when I've used dokuwiki in the past I've thought it was pretty nice/easy as far as wikis go.

Should we have an etherpad instance setup to fill the real-time collaboration need, as an alternative to google docs (for some subset of the google docs use case)?

-Shawn

On Tue, Aug 16, 2016 at 2:16 AM, Brian Behlendorf <bbehlendorf@...> wrote:
On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.

Willing to concede the point for now.

For the IP and attribution concerns,  does this apply to code only? Architecture white paper and requirements documents?

It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account.  I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs.

As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives.  That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. 

Here's an instance of Confluence running for another LF project, OPNFV: https://wiki.opnfv.org/

Note that they seem to use it for most of their community & web content.

Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires.

Brian



Jeremy


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.

Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.

We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian


Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.

Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 

Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.


That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.

E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.


I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian

Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@...>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)

Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).

From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.

-Shawn

On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@...> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:

Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.

-Shawn

On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@....

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@...
To: hyperledger-fabric <hyperledger-fabric@...>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@... [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 



_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@... https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

-- 
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric


Christopher B Ferris <chrisfer@...>
 

+1 to Etherpad
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
 

----- Original message -----
From: Brian Behlendorf <bbehlendorf@...>
Sent by: hyperledger-fabric-bounces@...
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@...
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
Date: Wed, Aug 24, 2016 12:24 AM
 
So we're now not going with Confluence - I'm having a Dokuwiki instance set up with the markdown plugin installed.

Brian

On 08/16/2016 07:49 AM, Shawn Amundson wrote:
 
About confluence...  Since it's not markdown or wiki syntax based, it is hard to pull information out.  It is also hard to paste text content into from terminal editors like vim (lots of time spent re-flowing line breaks).  Dokuwiki and mediawiki are open source and don't have those problems.  FWIW, when I've used dokuwiki in the past I've thought it was pretty nice/easy as far as wikis go.
 
Should we have an etherpad instance setup to fill the real-time collaboration need, as an alternative to google docs (for some subset of the google docs use case)?
 
-Shawn
 
On Tue, Aug 16, 2016 at 2:16 AM, Brian Behlendorf <bbehlendorf@...> wrote:
On 08/13/2016 06:48 AM, jeremysevareid wrote:
I agree that spreadsheets aren't as necessary if scope is just the build phase right now. Jira helps with that. However, spreadsheets may be worth revisiting when performance, scalability and integration testing come up.

Willing to concede the point for now.
 
For the IP and attribution concerns,  does this apply to code only? Architecture white paper and requirements documents?

It should for completeness' sake, and if integrated with one's linuxfoundation.org identity then we'll get that for free, I think, since one will have filled that out (the equivalent of a DCO) while setting up an account.  I see no need to anonymous contributions to a wiki at all, nor the architecture white paper and requirements docs.

As for use cases for a wiki - right now, I could use one to track our investigation into Slack and Mailman alternatives.  That's not a code-related thing, it's something where frequency of update and availability to all is more important than each commit being gerrit-reviewed. 

Here's an instance of Confluence running for another LF project, OPNFV: https://wiki.opnfv.org/

Note that they seem to use it for most of their community & web content.

Sensing that we've talked this pretty deeply, I will ask LF IT to set up a Confluence instance running next to our Jira, and we can kick the tires.

Brian
 
 
Jeremy


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 2:10 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
 
On 08/11/2016 10:56 AM, jeremysevareid wrote:
I agree on the PDF source file front.
 
Any preference for a spreadsheet tool? Ethercalc? Apache OpenOffice? Other?

Frankly all of them kind of suck for portability; if we're just using it to build a table of something, most wikis support tables, most in a wysiwyg way.
 
We're going to need one or something similar, in order to validate calcs,  ledger updates, perform reconciliations, etc.

Any examples of where today we use it in the _development_process_?  That would be new to me.  Would we really be using e.g. Excel for "ledger updates, perform reconciliations"?  I could see proper spreadsheets performing calculations as part of the documentation or white papers, perhaps. 

Brian
 
 
Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/11/2016 12:48 PM (GMT-05:00)
To: jeremysevareid <jeremysevareid@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
 
On 08/10/2016 08:34 PM, jeremysevareid wrote:
Wiki,  goggle docs and traditional file types like PDF,  PPT and xls are already in use by the requirements and identity work groups.
 
Right.  The goal should not be more tooling for tooling sake, but naming at least one as the preferred system of record, so that discovery, search-ability, and versioning are easier, as we do for software source code and issue tracking. Also, access to expensive proprietary tools required to edit powerpoint and excel files creates barriers to participation (not to mention those tools have very lousy version control systems if you try to operate outside Microsoft Sharepoint) The fewer attachments via email, the fewer links that are shared ad-hoc, the better the history of ideas can be traced so we can properly credit contributors and track IP, the better. 
 
Can we consider supporting both a wiki and an agreed range of checked-in doc file types?

Sure, though the checked-in doc types should be editable.  Too often PDFs are pretty pictures of information, but not really malleable or computable.  So long as the source is always in a repo of some sort (and easily changeable by other committers, without having to use proprietary software) that's fine.
 
 
That could give contributors more flexibility to choose the right tool and still provide the community with interoperable files under strong controls.
 
E.g., an exported wiki snapshot could be checked in and reviewed as part of a tagged release.  Exported Google, OpenOffice or MS docs, graphics and PDFs could as well.
 

I'd say anything included in a software release tarball should get the kind of formal review that Gerrit brings to the source code, since it's as important as the code itself, which also brings automatic conformance to a DCO.  I'm uncomfortable with the idea that someone might contribute something important in a Google doc, and then it would end up in a package, without a DCO.  Make that very uncomfortable. 

Often debates about "right tools" come down to a matter of familiarity and aesthetics rather than objective metrics.  Familiarity means ease of use which is important, at least for those already up to speed on that tool.  But the cost of disparate tooling (where 3 different tools are used for something that 1 tool would be acceptable for) is hard to measure, and still very real. 

Brian
 
Jeremy Sevareid | jeremysevareid@... | +1-917-538-3467


-------- Original message --------
From: Brian Behlendorf <bbehlendorf@linuxfoundation.org>
Date: 8/10/2016 11:15 AM (GMT-05:00)
To: Shawn Amundson <amundson@...>
Cc: hyperledger-fabric@lists.hyperledger.org
Subject: Re: [Hyperledger-fabric] Wikis? (was Re: issues for fabric)
 
Most projects figure out that line pretty organically.  The risk of limiting participation due to barriers to entry is high, and metrics hard to come by (how do you measure the people who wanted to edit but were turned off by the process).  Let's see how it goes with content very core to the code (like API docs) built from markdown in the source code repository, and other content in the wiki (bootstrapping with the current content), and shift docs from one to the other as seems appropriate, or tighten write privs to the wiki worst case (e.g., we start to see a lot of spam or drive-by changes).  I'll sign up to monitor wiki changes, as I hope others will.

We will still require an LF identity/account to edit the wiki, at which point we get the equiv of a DCO for their contributions.  No Wikipedia-style anonymous contributions.

Google docs can be great for some forms of collaboration, but if links to those docs aren't wired into a wiki or other parts of the project website, they run the risk of becoming forgotten cul-de-sacs.  Also, gdocs is blocked in some countries and increasingly across some corporate firewalls.

Brian

On 08/10/2016 06:58 AM, Shawn Amundson wrote:
Not sure how the project would successfully draw that line between what should be good proper docs and what should be unreviewed ad-hoc wiki docs.  A new-user how-to deserves at least as much refinement/thought as API documentation. Brainstorming pages are best done in something collaborative like google docs.  (wikis are non-collaborative - they neither provide pre-commit peer review nor multiple real-time editors).
 
From a practical legal perspective, it seems like you wouldn't want anything "real" to be written outside of the DCO process; if a great user's guide was written on the wiki by multiple authors, it seems like, regardless of quality, it could never be part of the project proper (and thus not version controlled, tagged, branched, etc.) without a big headache.
 
-Shawn
 
On Wed, Aug 10, 2016 at 12:07 AM, Brian Behlendorf <bbehlendorf@linuxfoundation.org> wrote:
Often, one benefit of a Wiki is that it provides a way to engage new developers or non-technical contributors in the development process, by making it easy to make the kind of small iterative simple improvements that often accompanies text editing, versus code development that is more about branches and pull requests and more formal reviews and processes.  Many open source communities feel comfortable granting write privs to the wiki broadly, even to anonymous users, on this basis, combined with premise that version control will always let us roll back in case of mistakes or spam (I'd probably recommend that here, actually, so long as we could make it easy to follow commits to the wiki, and have unified logins).  For more formal API and internal code documentation we do have a "readthedocs" section of the source code tree - does that use markdown?  Seems like that suffices for the uses you might be thinking of.  After all I can see API definitions and internal docs benefiting from more formal review than new-user how-to's or brainstorming pages.

Brian


On 08/09/2016 03:13 PM, Shawn Amundson wrote:
 
Sounds like an opportunity to switch away from a traditional wiki and move to a markdown language (sphinx-doc or similar) backed by git+Jenkins.  There are many benefits, including using the same review processes (gerrit, etc.) as we do with the rest of the source code.
 
-Shawn
 
On Mon, Aug 8, 2016 at 5:54 PM, Brian Behlendorf <bbehlendorf@...rg> wrote:
For the time being we can continue using the Github wiki, but to make the migration complete we should talk about setting up a separate wiki tool for the Hyperledger projects.  Currently, the LF infrastructure team would support either a Mediawiki or a Dokuwiki instance (if I recall correctly), for which we would also get single sign-on.  Does anyone here have a preferences?  This would be for a project-wide wiki so may be better to discuss on hyperledger-technical-discuss@lists.hyperledger.org.

Brian

On 08/08/2016 03:26 PM, Kondo, Yuki wrote:

Thanks, I understood that Jira will replace Github issue as well as Gerrit replaced Github Repository.

How about Github wiki? Do you have any plan to migrate wiki documents elsewhere?

 

Best Regards,

 

Yuki Kondo

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: Christopher B Ferris [mailto:chrisfer@...]
Sent: Monday, August 08, 2016 2:27 PM
To: Kondo, Yuki
Cc: hyperledger-fabric@...ledger.org
Subject: Re: [Hyperledger-fabric] issues for fabric

 

Jira issues replace the role of GitHub issues. Just a different tool - one that allows greater flexibility than GH.

If you find a bug, submit a Jira issue and if you are interested, you can also submit a patch via Gerrit and reference the Jira issue in the Commit message.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Kondo, Yuki" <Yuki.Kondo@...>
Sent by: hyperledger-fabric-bounces@lists.hyperledger.org
To: hyperledger-fabric <hyperledger-fabric@...rledger.org>
Cc:
Subject: Re: [Hyperledger-fabric] issues for fabric
Date: Mon, Aug 8, 2016 4:34 PM
 

Hello Chris. May I ask questions?

 

1) Process of issue discussion and bug fix

Currently, contributors submit issue/bug to Gerrit directly and reviewers check it.

How this process will change after migration to Jira?

 

2) Github Wiki document

Fabric has documents which are only stored on github wiki pages.

https://github.com/hyperledger/fabric/wiki

Where can I find these documents after migration to Gerrit & Jira has been completed?

 

Best Regards,

 

Yuki Kondo |近藤 佑樹

Hitachi America, Ltd., Research & Development Division

Tel: (408) 986-6460 | Mail: Yuki.Kondo@...

 

From: hyperledger-fabric-bounces@lists.hyperledger.org [mailto:hyperledger-fabric-bounces@...] On Behalf Of Gabor Hosszu
Sent: Monday, August 08, 2016 12:50 PM
To: hyperledger-fabric
Subject: Re: [Hyperledger-fabric] issues for fabric

 

+1 For the fresh start but I also agree with Arnaud's idea that we should try not to lose any important issue that is worth moving. :)

 

On Mon, Aug 8, 2016 at 9:15 PM, Christopher B Ferris <chrisfer@...> wrote:

+1 what Ry said, your LF credentials should work


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----Ry Jones <rjones@...> wrote: -----To: bob@...
From: Ry Jones <rjones@...>
Date: 08/08/2016 03:09PM
Cc: Christopher B Ferris/Waltham/IBM@IBMUS, hyperledger-fabric <hyperledger-fabric@...rledger.org>
Subject: Re: [Hyperledger-fabric] issues for fabric

The same credentials are used across any LF-managed property except the mailing list manager, so the same credentials should work on gerrit.hyperledger.org, jenkins.hyperledger.org, and jira.hyperledger.org.

On Mon, Aug 8, 2016 at 12:02 PM, Bob Summerwill <bob@...> wrote:
What login should be used for that JIRA instance, Chris?

My hyperledger.org credentials don't seem to work.   Should they?

How many different logins are required for a Hyperledger participant to use all the infrastructure at the moment?   Which are shared and which are separate?  Thanks!

 

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric




--

GABOR HOSSZU

 

​DEVELOPER




+​36 1 883 0300 

​gabor

@digitalasset.com
digitalasset.com


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

 

    
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...ledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@...ledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________ Hyperledger-fabric mailing list Hyperledger-fabric@lists.hyperledger.org https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric

 

--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric