Hi, I posted the agenda for this week's call: https://wiki.hyperledger.org/display/TSC/2019+10+03+TSC+Agenda I don't know how far we'll be able to go down the list of proposals but I tried to put firs

I agree, this all sounds good to me. -- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: "greg m" <greg_not_so@...> To: Brian Behlendorf <bbehlend

Hi all, I apologize for the late notice but I'm going to cancel this week's call due to a combination of a light agenda and logistical challenges on my end. I do want to point out that several quarter

Thank you all. I'm really honored to serve as chair. -- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: "Dan O'Prey via Lists.Hyperledger.Org" <dan=digit

Hi all, I find myself largely in agreement with the sentiment expressed by Shawn and Chris. I find it rather unfortunate that attempts to understand how Besu will fit in and what its addition means to

Thanks for this interesting info but to be clear, I for one never said that SIGs aren't doing any technical work. My only point is that SIGs don't report to the TSC. And until this changes, I think it

Hi Vipin, The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't. My point is that if the SIGs are actually doing technical work that should

Vipin, I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains. Regards. -- Arnaud Le Hors - Senior Technical Sta

The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with. Am I the only one to feel that way? -- Ar

I actually meant to say something about the fact that the whole point wasn't about penalizing people who have been absent as much as it was to make sure that their absence doesn't prevent the TSC from

I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.

I'm not sure where we ended with this discussion. I agree that we should do a better job at recording decisions and fully support the idea of building a compilation of all the TSC decisions. For refer

I don't really care how we call it, SIG or WG, but it's one of those in my opinion, and I agree with Hart that it is definitely not the Architecture WG. I'd make the charter something along the follow

My first reaction was similar to Chris's and Dan's - we don't need yet another group - but having thought about this a bit I'm actually in favor of creating a group dedicated to academic people. I thi

> 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 maki

> HL shouldn't dictate via TSC policy a requirement to sign up for survey monkey. There are a lot of ways to do it > without mandating a particular commercial service. says the guy who just wrote: > y

I strongly believe we need to give everyone a fair warning but I don't think we need to wait for several months to pull the trigger either. I'd say a month at most. This is independently of the fact t

Hi Ry, I share Shawn's uncertainty expressed earlier about what exactly from the Kubernetes management workflow you are proposing we adopt. Is it primarily the automagic management of the repos? Could

Hi all, I accepted last week to take the leadership on having another look at the Project Lifecycle to try and come up with a proposal to address the gaps that have surfaced over the last several mont

You're right, I was confused. Now, I understand. That's pretty cool! Thanks. :-) -- Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM From: David Huseby <dhuseby