On Fri, Sep 4, 2020 at 9:01 PM Brian Behlendorf <bbehlendorf@...> wrote: ... So for those who want to be involved in those design decisions around Transact - where do they go? Whether

On Fri, Sep 4, 2020 at 4:03 AM Duncan Johnston-Watt <duncan@...> wrote: ... My 2c is that given the variety of top level DLTs within the Hyperledger community and their very different arc

On Fri, Sep 4, 2020 at 3:35 AM Brian Behlendorf <bbehlendorf@...> wrote: ... But then... that enthusiasm seemed to fizzle. Like any such collaborative process, it can be awfully hard t

On Fri, Sep 20, 2019 at 12:32 PM Vipin Bharathan <vipinsun@...> wrote: ... This goes back to the idea that only code contributions matter- please broaden your outlook on what "technical contribu

We already have really good pluggable consensus within Hyperledger that supports both voting and lottery style consensus that is very close to being suitable for cross-project use. The next step is pa

Thanks Dan, very kind. I agree that Andi, Gari, and Tracy would be excellent TSC representatives. In addition, here is a shout out for all the other code-contributing maintainers as well: please vote

Sorry - finishing the thought there - We've considered Hashgraph in the past but were under the impression that it was patent encumbered.

I'm a big fan of the idea of top-level consensus projects. We've As a community, we've already had many conversations about consolidating what we already have across the existing projects. The effort

Another solution, which would scale better with a larger TSC, is to do voting async on the mailing list. -Shawn

The mechanics of the process (git vs. wiki) should be considered a secondary concern. And while I think that the github PR workflow has many usability and technical advantages over the wiki, I'd rathe

I love that location - close enough to go to Portland, which is a fantastic place. So from that perspective, I give this a +1. From a practical perspective, and maybe longer term, I think we need some

+1 For contributing, establishing a "help wanted" or similar list within JIRA for each project would also help for developers who want to contribute but aren't sure where to start. Unfortunately, it i

It would be better to call these "points of contact", as to not confuse it with a decision-making capability. Within some of the projects, we have a team of long-term maintainers for decision making,

I wouldn't describe Indy or Grid as a library. A lot of Grid is library/component stuff, but describing it that way in a taxonomy minimizes the overall project, because it does attempt to dictate some

Potential members, end-users, and developers are all going to be very different audiences. For the moment, it is probably pretty critical to keep planting more library projects and not make them invis

On Tue, Jun 11, 2019 at 11:47 PM Brian Behlendorf <bbehlendorf@...> wrote: ... Requiring a formal proposal template for all topics for TSC conversations, or those that would result in

As a project maintainer and part of the Hyperledger community, it is difficult to track what past decisions (especially related to policy) have been made by the TSC. The quality of proposals going to

I'd like to see more community involvement in these decisions and proposals. It may help for the TSC to select appoint some maintainers to the MC to ensure all the projects are represented in that for

We should probably fold the timing question into the lifecycle discussion, because it may depend on some of the other topics like whether everything goes through labs first. -Shawn

And... this is why we have peer review. :) Totally agree, it should be written in a way that describes the intent and not the tool. -Shawn