Date   

Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Brian Behlendorf
 

There are some basic things we need the developers involved with each effort within Labs to do (for example, using DCOs), and some things they should be doing (using processes that encourage contribution; using Git correctly; etc). Labs that don't do them create operational, reputational, and potentially legal liability for Hyperledger. That liability is on the shoulders of the TSC and Governing Board, who delegate it down to the Labs stewards.

If the Labs stewards are happy policing for and enforcing the things that must be done, and working with communities on the things that should be done, then great. But the point of Sponsors has always been to fan out those responsibilities and efforts to a larger group who could be trusted to perform those roles. Attaching that limit to other maintainers helped ensure it was people who understood those needs and shoulds (though we could always do a better job documenting them). If there aren't enough volunteers for that work, that quite reasonably sets a limit to the number of projects we should have in Labs. It had very little to do with evaluating the quality of a Labs proposal, except to infer that poor quality proposals might not attract a qualified Sponsor.

The TSC can choose to do away with the Sponsor requirement, but not with the responsibilities for governance. If that's preferred, let's just create a page linking to github repositories (hosted by other organizations) of projects we think are doing good things but are otherwise not overseeing.

Brian

On 2/8/21 6:34 AM, VIPIN BHARATHAN wrote:
Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)


From: Arun .S.M. <arun.s.m.cse@...>
Sent: Monday, February 8, 2021 9:05 AM
To: VIPIN BHARATHAN <vip@...>
Cc: tracy.a.kuhrt@... <tracy.a.kuhrt@...>; lehors@... <lehors@...>; SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


-- 
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Christopher Ferris
 

This thread contains lots of good advice, but no practical actionable recommendations.
 
The reality is that some of the projects offer more comprehensive guidance for contributors than others. Those are more
likely to attract contributors. Retaining them is another issue entirely.
 
Without getting into specific criticisms, I would note that some of the projects do indeed make it difficult to find
(or impossible) how to contribute and that every project could use some introspection/reflection.
 
Someone observed that each project handles things differently, which is very true. We couldn't impose a specific
process on all for any number of reasons. However, assembling the advice in this thread, and which many of us have
internalized over time to be easily shared for new or foundering projects would be a useful exercise.
 
FWIW, I think Fabric and Besu seem to have the most comprehensive guidance and are worthy of emulation. One last thought,
projects with multiple repositories should ideally link their collective repos to a single canonical and authoritative CONTRIBUTING.md.
 
Cheers,

Christopher Ferris IBM Fellow, CTO Open Technology
twitter: @christo4ferris | phone: +1 508 667 0402 | blog: 
https://developer.ibm.com/profiles/chrisfer/
 
 

----- Original message -----
From: "Sean Young" <sean@...>
Sent by: tsc@...
To: Ry Jones <rjones@...>
Cc: Arun S M <arun.s.m.cse@...>, David Boswell <dboswell@...>, Tracy Kuhrt <tracy.a.kuhrt@...>, "tsc@..." <tsc@...>, "SIG-Chairs@..." <SIG-Chairs@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors
Date: Mon, Feb 8, 2021 1:14 PM
 
Hi Ry,

On Mon, Feb 08, 2021 at 10:06:27AM -0800, Ry Jones wrote:
> We do have some of this information in the Hyperledger overview
> <https://tinyurl.com/yyenka9n >; that data is available per-project (and
> per-repo) as well.
>
> There is also timing data <https://tinyurl.com/yy87mzhr >.

That is good; better is if this is documented for potential contributers.
This gives a warm fuzzy feeling of "my contribution is welcome here".

Much more so than reading the tealeaves of how a project behaves.


Thanks

Sean

> Ry
>
> On Mon, Feb 8, 2021 at 9:49 AM Sean Young <sean@...> wrote:
>
> > 1. Time to review a PR
> >    Users should know that their PR will get a full review within e.g.
> >    14 days. Escalation routes should be documented, e.g. post in this
> >    rocketchat channel "my PR has not been reviewed, it has been 14 days".
> >
> >    This includes every re-review after rework.
> >
> --
> Ry Jones
> Community Architect, Hyperledger
> Chat <https://www.youtube.com/watch?v=EEc4JRyaAoA >: @rjones
> <https://chat.hyperledger.org/direct/rjones > Calendar
> <https://calendly.com/ryjones >




 
 


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Sean Young
 

Hi Ry,

On Mon, Feb 08, 2021 at 10:06:27AM -0800, Ry Jones wrote:
We do have some of this information in the Hyperledger overview
<https://tinyurl.com/yyenka9n>; that data is available per-project (and
per-repo) as well.

There is also timing data <https://tinyurl.com/yy87mzhr>.
That is good; better is if this is documented for potential contributers.
This gives a warm fuzzy feeling of "my contribution is welcome here".

Much more so than reading the tealeaves of how a project behaves.


Thanks

Sean

Ry

On Mon, Feb 8, 2021 at 9:49 AM Sean Young <sean@mess.org> wrote:

1. Time to review a PR
Users should know that their PR will get a full review within e.g.
14 days. Escalation routes should be documented, e.g. post in this
rocketchat channel "my PR has not been reviewed, it has been 14 days".

This includes every re-review after rework.
--
Ry Jones
Community Architect, Hyperledger
Chat <https://www.youtube.com/watch?v=EEc4JRyaAoA>: @rjones
<https://chat.hyperledger.org/direct/rjones> Calendar
<https://calendly.com/ryjones>


Re: SIG Request for Support from Technical Community: Defining Standards

Brian Behlendorf
 

(I've moved SIG-chairs to Bcc so that they're not caught in follow-up replies as a courtesy, but feel free to follow along on the TSC list)

Recently, the Linux Foundation has done more with open specifications as they relate to software work, and specifically in ways to enable "umbrella" projects like ours to have a separately chartered project that can focus on specifications. See here:

We could launch a Hyperledger specifications project (or series of projects), operating based on this CommunitySpecification process.

It would require:

1) Use of a Contributor License Agreement for anyone participating in that project (this is separate from / above our standard DCO)

2) The drafting of a scope for specifications within that project - so we should discuss level of granularity, do we have a project focused on Aries-ish specifications, anything identity, or anything DLT-related? We can have more than one such spec project, but they'll each require Governing Board approval.

3) Committed volunteers from the TSC or community to help us keep the process on track - the scope of which isn't yet clear to me. It is clear that we need a champion or two for this idea to come from the community - it's not something I'll push top-down.

4) It would be a best practice for the name of these specs to be different from the name of HL software packages, so that independent implementations aren't discouraged.

There are likely other ramifications; maybe those who've been involved with TOIP or other such CommunitySpecification-based efforts can share what they've experienced.

I'm not convinced that the Aries specification work wouldn't be better handled at TOIP than at HL, or that we have other useful standards work to that couldn't be better handled elsewhere. But I will say if a neutral zone like this has been a barrier to collaboration even just between our own projects, that's a great reason to do something along these lines at HL.

Any takers?

Brian

On 2/8/21 6:28 AM, VIPIN BHARATHAN wrote:
Hi all,

I have heard from Brian several times that Hyperledger is not a standards organization, which stands to reason.  
There is a survey of Blockchain standards in GSMI. This illustrates the dictum that standards are so great because there are so many of them.
One of the points that GSMI brought up is the need for the SDOs (Standards Development Organizations) to co-ordinate, plus the fact that orgs like ISO are closed to regular folks and that they charge a lot for their standards.

I chair the Interoperability workstream in Digital Currency Global Initiative (DCGI) - a collaboration between ITU-T (an SDO) and Stanford. This is open for participation and one of their methods is to study use cases for extracting common elements and the state of the art of implementations which are far in advance of standards settings. I invite the HL cactus folks to present on this topic.  The DCGI will publish a roadmap towards standards for Digital Currencies, the ur-use case for Blockchain. The working groups in DCGI include Policy & Governance, Architecture, & Security. 

Best

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via lists.hyperledger.org <lehors=us.ibm.com@...>
Sent: Monday, February 8, 2021 7:43 AM
To: tracy.a.kuhrt@... <tracy.a.kuhrt@...>
Cc: SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
 
Hi,
I think this actually raises a couple of issues.

The first one is the framework to develop standards within Hyperledger. Hyperledger wasn't set up to develop standards. The belief was that this would be done in other organizations and we would merely focus on implementation. That question was recently raised in the context of the Aries project which has been in fact developing a specification. I will let Brian speak up about what we can do here.

The second one is a question of socialization of the work happening in different parts of Hyperledger. This is a need we have across Hyperledger. The TSC has had several discussions about what we could do to help projects know more about each other so that opportunities for collaboration could be seized - projects often work on similar topics in isolation due to a lack of awareness. We clearly haven't figured this one out yet and ought to give this another look.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:01 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #1 Defining standards -- data standards, process standards.  How to get standards to interoperate.  How to break things out of silos since different SIGs are working on standards in separate groups.  Can presenting these standards efforts to the TSC help break these out of standards?  Can the technical community help with implementation of the standards?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Do we need to streamline the outcomes of these standardization activities? TSC can help here by reviewing current modes of collaboration. Another way TSC can be involved is to review the content as you suggested. TSC could guide SIGs on what is possible, already available, what alternatives are available, be able to bridge to other similar outcomes. This will help TSC in a way to respond to project needs and requests.

 

Tracy

 





This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




-- 
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Ry Jones
 

We do have some of this information in the Hyperledger overview; that data is available per-project (and per-repo) as well.

There is also timing data.
Ry


On Mon, Feb 8, 2021 at 9:49 AM Sean Young <sean@...> wrote:
1. Time to review a PR
   Users should know that their PR will get a full review within e.g.
   14 days. Escalation routes should be documented, e.g. post in this
   rocketchat channel "my PR has not been reviewed, it has been 14 days".

   This includes every re-review after rework.
--
Ry Jones
Community Architect, Hyperledger


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Sean Young
 

On Sat, Feb 06, 2021 at 06:50:36PM +0530, Arun S M wrote:
Adding onto this discussion,

The entry barriers that I have found while asking the developer community
to get involved are
1. First time contributors think that they need to spend a significant
amount of time before making attempts to contribute. They are unsure of
their code acceptance by a project.
I think this is part of a larger problem. When contributing to any project,
you don't know what the response is going to be to PR. I think many of
us have invested time into a pull request and it just is ignored or you
just a get snotty response.

I think projects need to have clearly defined rules for maintainers:

1. Time to review a PR
Users should know that their PR will get a full review within e.g.
14 days. Escalation routes should be documented, e.g. post in this
rocketchat channel "my PR has not been reviewed, it has been 14 days".

This includes every re-review after rework.

2. A pull request should be taken seriously (or "listened to")
A pull request might not be useful, but the user is experiencing a
problem they would like to solve. This should be discussed, and handled
appropriately. Explore the root issue.

There is a wonderful blog series on this issue:

http://aturon.github.io/tech/2018/05/25/listening-part-1/

3. Expectations of code style, testing etc. should be documented.
All known requirements should be documented, so that whoever writes
a PR knows what to expect.

There can be exceptions for "RFC" PRs.

4. Expectations for merged PR to present in a release
Once a PR is merged, the next question is always, when is it in a
release. A documented release cycle really helps here.

There are probably more things but I can't think of them now.

2. Lack of awareness on available opportunities to get involved.
I think most users want to contribute specific issues that are bothering
them. A few would like to contribute but do not know where to start; usually
these are very new users.

3. Number of reworks on a PR. due to lack of information on better
practices followed at Hyperledger.
Absolutely, if there was standard practise for a project, it should be
clearly documentated.


Sean


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Hart Montgomery
 

Hi Arun,

Thanks for bringing this up to everyone.  I think #1, in particular, is a big issue.  Most projects have their own specific PR requirements that can be difficult to get right on the first time.  Maintainers also tend to respond to and deal with PRs from people that they know more quickly, and PRs from unknown contributors that are useful but maybe do a couple of things wrong because the contributors are new can get "black holed."  I guess this plays into #3 as well.

Two things that I've recommended for these problems in some of the projects I've worked on are as follows:
  1. Require that maintainers address PRs in order (except for some critical fixes).  This means that people cannot just skip PRs for people that they don't know, and must respond to all PRs in a timely manner.  
  2. Never close someone's PR without explaining why.  Even if it's a totally foolish PR, at least a sentence or two is required.
I think these rules help reduce discouragement for new people trying PRs.  I don't think we want to regulate things at a Hyperledger level, but I did want to share things that seem to work for projects that I work on/follow closely.

Thanks a lot for your time, and have a great day.

Hart


From: tsc@... <tsc@...> on behalf of Arun S M <arun.s.m.cse@...>
Sent: Saturday, February 6, 2021 5:20 AM
To: David Boswell <dboswell@...>
Cc: Tracy Kuhrt <tracy.a.kuhrt@...>; tsc@... <tsc@...>; SIG-Chairs@... <SIG-Chairs@...>
Subject: Re: [Hyperledger TSC] [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors
 
Adding onto this discussion,

The entry barriers that I have found while asking the developer community to get involved are
1. First time contributors think that they need to spend a significant amount of time before making attempts to contribute. They are unsure of their code acceptance by a project.
2. Lack of awareness on available opportunities to get involved.
3. Number of reworks on a PR. due to lack of information on better practices followed at Hyperledger.

Building upon the idea of aggregating contribution opportunities at one place, and similar discussions I have had with another project in Hyperledger.
How about also categorizing those opportunities into different verticals?
- Documentation efforts for those who wish to help out there.
- Porting efforts, if somebody is new to a programming language or doesn't know about a project. Here are low hanging fruits/easy picks.
- Adding to the test coverage, implementing fully designed modules. For a slightly mature developer.
- A section for specific requirements. For example, call out need for help on expertise from verifiable credentials use cases, call out need to work on a setting up a test network, call out need to work on a backend. This way specific people interested in a domain can even subscribe to available opportunities.
- Influencing the roadmap of a project. This is where the passionate developers/organizations join by themselves.

Weekly dev letters can be used to publish a link to this page. Also, highlight new opportunities added upon here.

Regards,
Arun

On Sat, Feb 6, 2021 at 4:19 AM David Boswell <dboswell@...> wrote:
Out of all of the ideas that came out of that discussion, I think this one about rolling up contribution opportunities could bring the most benefit to the entire community.

Right now a potential contributor needs to look at 72 different places (16 projects, 42 labs repositories, 5 Working Groups, 9 Special Interest Groups) to get a full picture of what they can contribute to.  Having one place that aggregates everything that they could contribute to would be a much lower barrier to entry.

And bringing all contribution opportunities together in one place could promote collaboration among different parts of the community.  It seems entirely possible that different groups are working separately on similar tasks without realizing it because there isn't a lot of visibility across the whole of the community.  Could we get a better sense of where to combine efforts if we did roll opportunities up?

It seems like it should be possible to have one page on the wiki that aggregates all 'help wanted' and/or all 'good first issues'.  Last year Ry installed a Confluence plug-in that let us embed Github issues onto a wiki page (see example at link below) and that could be the basis of something that pulled from a wider collection of sources.


Thanks,
David

On Thu, Feb 4, 2021 at 2:02 PM Kuhrt, Tracy A. via lists.hyperledger.org <tracy.a.kuhrt=accenture.com@...> wrote:

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.

 

Tracy




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

VIPIN BHARATHAN
 

Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: Arun .S.M. <arun.s.m.cse@...>
Sent: Monday, February 8, 2021 9:05 AM
To: VIPIN BHARATHAN <vip@...>
Cc: tracy.a.kuhrt@... <tracy.a.kuhrt@...>; lehors@... <lehors@...>; SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


Re: SIG Request for Support from Technical Community: Defining Standards

VIPIN BHARATHAN
 

Hi all,

I have heard from Brian several times that Hyperledger is not a standards organization, which stands to reason.  
There is a survey of Blockchain standards in GSMI. This illustrates the dictum that standards are so great because there are so many of them.
One of the points that GSMI brought up is the need for the SDOs (Standards Development Organizations) to co-ordinate, plus the fact that orgs like ISO are closed to regular folks and that they charge a lot for their standards.

I chair the Interoperability workstream in Digital Currency Global Initiative (DCGI) - a collaboration between ITU-T (an SDO) and Stanford. This is open for participation and one of their methods is to study use cases for extracting common elements and the state of the art of implementations which are far in advance of standards settings. I invite the HL cactus folks to present on this topic.  The DCGI will publish a roadmap towards standards for Digital Currencies, the ur-use case for Blockchain. The working groups in DCGI include Policy & Governance, Architecture, & Security. 

Best

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via lists.hyperledger.org <lehors=us.ibm.com@...>
Sent: Monday, February 8, 2021 7:43 AM
To: tracy.a.kuhrt@... <tracy.a.kuhrt@...>
Cc: SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
 
Hi,
I think this actually raises a couple of issues.

The first one is the framework to develop standards within Hyperledger. Hyperledger wasn't set up to develop standards. The belief was that this would be done in other organizations and we would merely focus on implementation. That question was recently raised in the context of the Aries project which has been in fact developing a specification. I will let Brian speak up about what we can do here.

The second one is a question of socialization of the work happening in different parts of Hyperledger. This is a need we have across Hyperledger. The TSC has had several discussions about what we could do to help projects know more about each other so that opportunities for collaboration could be seized - projects often work on similar topics in isolation due to a lack of awareness. We clearly haven't figured this one out yet and ought to give this another look.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:01 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #1 Defining standards -- data standards, process standards.  How to get standards to interoperate.  How to break things out of silos since different SIGs are working on standards in separate groups.  Can presenting these standards efforts to the TSC help break these out of standards?  Can the technical community help with implementation of the standards?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Do we need to streamline the outcomes of these standardization activities? TSC can help here by reviewing current modes of collaboration. Another way TSC can be involved is to review the content as you suggested. TSC could guide SIGs on what is possible, already available, what alternatives are available, be able to bridge to other similar outcomes. This will help TSC in a way to respond to project needs and requests.

 

Tracy

 





This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Arun S M
 

It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

VIPIN BHARATHAN
 

As a lab steward I agree with Arnaud on this one. We struggle all the time with lab proposers looking for sponsors. I have stepped in numerous times to sponsor projects that I find worthy. Nothing should stand in the way of contributions to labs.
Best,
Vipin


dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via lists.hyperledger.org <lehors=us.ibm.com@...>
Sent: Monday, February 8, 2021 7:58 AM
To: tracy.a.kuhrt@... <tracy.a.kuhrt@...>
Cc: SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
To the risk of sounding like a broken record, I would like the TSC to consider (again) dropping the requirement for a Lab Sponsor. The whole point of requiring lab proposals to have a sponsor was to filter out possible junk that might be submitted. I claim that the Lab Stewards can do that, and in fact already do that, just fine.

Since the last time I made this proposal it was turned down, I will ask that anyone who insists on keeping the requirement for a Lab Sponsor be put on the list of possible sponsors advertised to lab proposers. :-)
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:02 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #3 Labs and technical documents have been created in isolation so far and don’t tend to connect with projects.  Would papers that SIGs created have value for the TSC and for projects in terms of requirements?  Are there ways we can make the Labs process better?  Vipin shared that there were many difficulties using Labs for the Telecom SIG.  Can we review the current Labs process to see how we can remove roadblocks and make it easier?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Tracy:

it seems that there may be some friction in the current lab process that is limiting the usefulness of the Hyperledger Labs for SIGs. It would be helpful to hear from people who have attempted to create a lab and ran into struggles. One of those struggles that we have talked about in the past is the Lab Sponsor. We have discussed how best to gather a list of people who would be willing to act as a sponsor that we could link to within the overall Labs process.

 

From Arun:

Let us request Vipin to join one of the TSC meetings and list down each of the concerns. I remember, this topic due for discussion along with struggles that a project faced to move from incubation to active state. My personal experience of raising a new labs request has been an easy and swift.

 

Tracy





This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Arnaud Le Hors
 

To the risk of sounding like a broken record, I would like the TSC to consider (again) dropping the requirement for a Lab Sponsor. The whole point of requiring lab proposals to have a sponsor was to filter out possible junk that might be submitted. I claim that the Lab Stewards can do that, and in fact already do that, just fine.

Since the last time I made this proposal it was turned down, I will ask that anyone who insists on keeping the requirement for a Lab Sponsor be put on the list of possible sponsors advertised to lab proposers. :-)
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:02 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #3 Labs and technical documents have been created in isolation so far and don’t tend to connect with projects.  Would papers that SIGs created have value for the TSC and for projects in terms of requirements?  Are there ways we can make the Labs process better?  Vipin shared that there were many difficulties using Labs for the Telecom SIG.  Can we review the current Labs process to see how we can remove roadblocks and make it easier?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Tracy:

it seems that there may be some friction in the current lab process that is limiting the usefulness of the Hyperledger Labs for SIGs. It would be helpful to hear from people who have attempted to create a lab and ran into struggles. One of those struggles that we have talked about in the past is the Lab Sponsor. We have discussed how best to gather a list of people who would be willing to act as a sponsor that we could link to within the overall Labs process.

 

From Arun:

Let us request Vipin to join one of the TSC meetings and list down each of the concerns. I remember, this topic due for discussion along with struggles that a project faced to move from incubation to active state. My personal experience of raising a new labs request has been an easy and swift.

 

Tracy





This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Re: SIG Request for Support from Technical Community: Defining Standards

Arnaud Le Hors
 

Hi,
I think this actually raises a couple of issues.

The first one is the framework to develop standards within Hyperledger. Hyperledger wasn't set up to develop standards. The belief was that this would be done in other organizations and we would merely focus on implementation. That question was recently raised in the context of the Aries project which has been in fact developing a specification. I will let Brian speak up about what we can do here.

The second one is a question of socialization of the work happening in different parts of Hyperledger. This is a need we have across Hyperledger. The TSC has had several discussions about what we could do to help projects know more about each other so that opportunities for collaboration could be seized - projects often work on similar topics in isolation due to a lack of awareness. We clearly haven't figured this one out yet and ought to give this another look.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:01 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #1 Defining standards -- data standards, process standards.  How to get standards to interoperate.  How to break things out of silos since different SIGs are working on standards in separate groups.  Can presenting these standards efforts to the TSC help break these out of standards?  Can the technical community help with implementation of the standards?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Do we need to streamline the outcomes of these standardization activities? TSC can help here by reviewing current modes of collaboration. Another way TSC can be involved is to review the content as you suggested. TSC could guide SIGs on what is possible, already available, what alternatives are available, be able to bridge to other similar outcomes. This will help TSC in a way to respond to project needs and requests.

 

Tracy

 





This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




Re: SIG Request for Support from Technical Community: Sharing what groups are doing with TSC through presentations

Arnaud Le Hors
 

Hi,

I actually don't think more discussion is really needed on this point. The TSC supports the idea of having SIGs come and present to the TSC. I therefore invite SIG chairs to contact me to schedule a presentation if they are interested. We normally meet on Thursdays and can easily accommodate if it's planned a week or two ahead of time. We should aim for a 20mn presentation.

Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:04 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Sharing what groups are doing with TSC through presentations
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #6 Sharing what groups are doing with TSC through presentations.

 

We did not really have any discussion on this topic in the other thread other than a +1 from Arun that sharing information will help solve a lot of problems. I will add that we seem to be in agreement that having groups come to the TSC and present is a good thing to do. Are there thoughts on the timing/scheduling of getting groups to present to the TSC?

 

Tracy

 





This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at
https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com




[Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Alfonso Govela Thomae
 

FYI

Begin forwarded message:

From: Alfonso Govela Thomae <alfonsogovela@...>
Subject: Re: [Hyperledger TSC] [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors
Date: February 6, 2021 at 6:34:53 PM CST
Cc: Alfonso Govela Thomae <alfonsogovela@...>, David Boswell <dboswell@...>, Tracy Kuhrt <tracy.a.kuhrt@...>, "tsc@..." <tsc@...>, "SIG-Chairs@..." <SIG-Chairs@...>, Bobbi Muscara <bobbi@...>

Thank you Arun for your ideas. I fully agree with you.

LMDWG, Learning Materials and Development Working Group, can be a landing page for aggregated contribution opportunities…

What do you think?

On Feb 6, 2021, at 7:20 AM, Arun .S.M. via lists.hyperledger.org <arun.s.m.cse=gmail.com@...> wrote:

Adding onto this discussion,

The entry barriers that I have found while asking the developer community to get involved are
1. First time contributors think that they need to spend a significant amount of time before making attempts to contribute. They are unsure of their code acceptance by a project.
2. Lack of awareness on available opportunities to get involved.
3. Number of reworks on a PR. due to lack of information on better practices followed at Hyperledger.

Building upon the idea of aggregating contribution opportunities at one place, and similar discussions I have had with another project in Hyperledger.
How about also categorizing those opportunities into different verticals?
- Documentation efforts for those who wish to help out there.
- Porting efforts, if somebody is new to a programming language or doesn't know about a project. Here are low hanging fruits/easy picks.
- Adding to the test coverage, implementing fully designed modules. For a slightly mature developer.
- A section for specific requirements. For example, call out need for help on expertise from verifiable credentials use cases, call out need to work on a setting up a test network, call out need to work on a backend. This way specific people interested in a domain can even subscribe to available opportunities.
- Influencing the roadmap of a project. This is where the passionate developers/organizations join by themselves.

Weekly dev letters can be used to publish a link to this page. Also, highlight new opportunities added upon here.

Regards,
Arun

On Sat, Feb 6, 2021 at 4:19 AM David Boswell <dboswell@...> wrote:
Out of all of the ideas that came out of that discussion, I think this one about rolling up contribution opportunities could bring the most benefit to the entire community.

Right now a potential contributor needs to look at 72 different places (16 projects, 42 labs repositories, 5 Working Groups, 9 Special Interest Groups) to get a full picture of what they can contribute to.  Having one place that aggregates everything that they could contribute to would be a much lower barrier to entry.

And bringing all contribution opportunities together in one place could promote collaboration among different parts of the community.  It seems entirely possible that different groups are working separately on similar tasks without realizing it because there isn't a lot of visibility across the whole of the community.  Could we get a better sense of where to combine efforts if we did roll opportunities up?

It seems like it should be possible to have one page on the wiki that aggregates all 'help wanted' and/or all 'good first issues'.  Last year Ry installed a Confluence plug-in that let us embed Github issues onto a wiki page (see example at link below) and that could be the basis of something that pulled from a wider collection of sources.


Thanks,
David

On Thu, Feb 4, 2021 at 2:02 PM Kuhrt, Tracy A. via lists.hyperledger.org<tracy.a.kuhrt=accenture.com@...> wrote:
On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.

 

Tracy




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy. 
______________________________________________________________________________________

www.accenture.com






Regarding Maintainers Summit

Arun S M
 

Hello all,

In the TSC meeting run on 4th Feb, the question on the need to have a maintainers summit was brought up. It was also noted that due to lack of replies/participation, it could be reconsidered for later dates when travel around the world is reopened. I couldn't find the earlier thread on it, so I started this one. Most of the TSC members alluded to the need to have discussions with specific project maintainers. I have few more comments on the benefits of this summit/engagement, doing it now.

1. Could be a touch point to discuss the project charter that was agreed upon in earlier summits.
2. If the outcome of this summit is that there is a need for quick prototyping, trying out something. Hyperledger Mentorship can become a way to achieve it. Avoids extra resource requirements to a large extent.

Regards,
Arun


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Arun S M
 

Adding onto this discussion,

The entry barriers that I have found while asking the developer community to get involved are
1. First time contributors think that they need to spend a significant amount of time before making attempts to contribute. They are unsure of their code acceptance by a project.
2. Lack of awareness on available opportunities to get involved.
3. Number of reworks on a PR. due to lack of information on better practices followed at Hyperledger.

Building upon the idea of aggregating contribution opportunities at one place, and similar discussions I have had with another project in Hyperledger.
How about also categorizing those opportunities into different verticals?
- Documentation efforts for those who wish to help out there.
- Porting efforts, if somebody is new to a programming language or doesn't know about a project. Here are low hanging fruits/easy picks.
- Adding to the test coverage, implementing fully designed modules. For a slightly mature developer.
- A section for specific requirements. For example, call out need for help on expertise from verifiable credentials use cases, call out need to work on a setting up a test network, call out need to work on a backend. This way specific people interested in a domain can even subscribe to available opportunities.
- Influencing the roadmap of a project. This is where the passionate developers/organizations join by themselves.

Weekly dev letters can be used to publish a link to this page. Also, highlight new opportunities added upon here.

Regards,
Arun

On Sat, Feb 6, 2021 at 4:19 AM David Boswell <dboswell@...> wrote:
Out of all of the ideas that came out of that discussion, I think this one about rolling up contribution opportunities could bring the most benefit to the entire community.

Right now a potential contributor needs to look at 72 different places (16 projects, 42 labs repositories, 5 Working Groups, 9 Special Interest Groups) to get a full picture of what they can contribute to.  Having one place that aggregates everything that they could contribute to would be a much lower barrier to entry.

And bringing all contribution opportunities together in one place could promote collaboration among different parts of the community.  It seems entirely possible that different groups are working separately on similar tasks without realizing it because there isn't a lot of visibility across the whole of the community.  Could we get a better sense of where to combine efforts if we did roll opportunities up?

It seems like it should be possible to have one page on the wiki that aggregates all 'help wanted' and/or all 'good first issues'.  Last year Ry installed a Confluence plug-in that let us embed Github issues onto a wiki page (see example at link below) and that could be the basis of something that pulled from a wider collection of sources.


Thanks,
David

On Thu, Feb 4, 2021 at 2:02 PM Kuhrt, Tracy A. via lists.hyperledger.org <tracy.a.kuhrt=accenture.com@...> wrote:

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.

 

Tracy




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

David Boswell
 

Out of all of the ideas that came out of that discussion, I think this one about rolling up contribution opportunities could bring the most benefit to the entire community.

Right now a potential contributor needs to look at 72 different places (16 projects, 42 labs repositories, 5 Working Groups, 9 Special Interest Groups) to get a full picture of what they can contribute to.  Having one place that aggregates everything that they could contribute to would be a much lower barrier to entry.

And bringing all contribution opportunities together in one place could promote collaboration among different parts of the community.  It seems entirely possible that different groups are working separately on similar tasks without realizing it because there isn't a lot of visibility across the whole of the community.  Could we get a better sense of where to combine efforts if we did roll opportunities up?

It seems like it should be possible to have one page on the wiki that aggregates all 'help wanted' and/or all 'good first issues'.  Last year Ry installed a Confluence plug-in that let us embed Github issues onto a wiki page (see example at link below) and that could be the basis of something that pulled from a wider collection of sources.


Thanks,
David


On Thu, Feb 4, 2021 at 2:02 PM Kuhrt, Tracy A. via lists.hyperledger.org <tracy.a.kuhrt=accenture.com@...> wrote:

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.

 

Tracy




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


SIG Request for Support from Technical Community: Sharing what groups are doing with TSC through presentations

Kuhrt, Tracy A.
 

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #6 Sharing what groups are doing with TSC through presentations.

 

We did not really have any discussion on this topic in the other thread other than a +1 from Arun that sharing information will help solve a lot of problems. I will add that we seem to be in agreement that having groups come to the TSC and present is a good thing to do. Are there thoughts on the timing/scheduling of getting groups to present to the TSC?

 

Tracy

 




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


SIG Request for Support from Technical Community: Technical contributors

Kuhrt, Tracy A.
 

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.

 

Tracy




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com

261 - 280 of 3559