|
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.
-----
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!
--
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
--
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:
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
|
|
|
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:
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@linuxfoundation.org
Twitter: @brianbehlendorf
_______________________________________________
Hyperledger-fabric mailing list
Hyperledger-fabric@lists.hyperledger.org
https://lists.hyperledger.org/mailman/listinfo/hyperledger-fabric
--
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.
-----
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!
--
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
--
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.
|
|
|
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
--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
|
|
|
Christopher B Ferris <chrisfer@...>
toggle quoted messageShow quoted text
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
|
|
|
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
--
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
--
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
toggle quoted messageShow quoted text
-------- 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
--
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
-------- 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
--
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
toggle quoted messageShow quoted text
-------- 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
-------- 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
--
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
-------- 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
-------- 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
--
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
toggle quoted messageShow quoted text
-------- 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
-------- 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
-------- 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
--
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
-------- 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
-------- 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
--
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
-------- 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
-------- 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
--
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
--
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
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
--
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@...>
toggle quoted messageShow quoted text
----- 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
-------- 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
-------- 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. ----- 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!
--
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.
--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...g
Twitter: @brianbehlendorf
--
Brian Behlendorf
Executive Director at the Hyperledger Project
bbehlendorf@...
Twitter: @brianbehlendorf
|
|
|
