I agree also ? specializations in project repos is a natural way to focus contributors with different skill sets. That?s one of the reasons for my ?multiple repos per project? comment. Often I see docs and code (at least) being managed in separate repos, under a single project. Code can be further managed in separate repos (e.g. service and client as in OpenStack). Thus the committers to those repos have the meritocratic history in the related skills and artifacts, centered around the purpose for the repo (which nonetheless can host artifacts of various types, e.g. user guides/readmes, unit tests, ? even if it?s mostly focused on one type of artifact).
The comment about using the generic ?contribution? term (vs code) was to reflect those various types of contribution as the prerequisite to being a committer, of whatever focus. So overall I think we are in agreement. Thanks, Bryan Sullivan | AT&T From: Ed Warnicke [mailto:[email protected]] Sent: Wednesday, April 19, 2017 12:59 PM To: SULLIVAN, BRYAN L <bs3131 at att.com> Cc: Christopher Donley (Chris) <Christopher.Donley at huawei.com>; onap-tsc at lists.onap.org; Ed Warnicke <eaw at cisco.com> Subject: Re: [onap-tsc] Updated TSC Charter Bryan, I agree with you that it's good to get architecture documents in git repos managed via gerrit :) That's pure goodness. The essense of committerness is the ability to merge a patch into a project's repo. Because of this a committer should have expertise appropriate to exercising that ability. One highly productive way I've seen this handled in other communities is to have your 'code' project, where the metric for committerness is code contribution as a demonstration of merit. System test often has its own, separate project because the skillset for producing good system tests is often distinct from the skillset for generating good underlying code, and is often written in different languages with different tools. Similarly for 'user facing docs' and 'architecture docs'. By having them be separate projects with separate committer pools, you select for people with the correct skillset to make decisions about merging to each. This makes things fairly simple. People become committers on 'code' projects by contributing code, on testing projects by contributing testing, on user facing doc projects by contributing user facing docs, and on architecture doc projects by contributing to architecture docs. It also has the nice effect of building communities around each function that value each kind of contribution. Ed On Wed, Apr 19, 2017 at 11:07 AM, SULLIVAN, BRYAN L <bs3131 at att.com<mailto:bs3131 at att.com>> wrote: Yes, IMO architecture as documented should be managed thru gerrit. Discussions and preliminary proposals can be on wikis etc (even etherpads), but at some point a document is written, reviewed, and change-managed. Those stages should be managed thru gerrit using a document format that works for the community. I recommend git/gerrit-friendly formats e.g. RST which can also incorporate rich text artifacts (e.g. diagrams). But even pure rich-text format docs can be reviewed thru gerrit if the proposed changes are adequately summarized in the commit message and comments to it. Thanks, Bryan Sullivan | AT&T From: Ed Warnicke [mailto:hagbard at gmail.com<mailto:[email protected]>] Sent: Wednesday, April 19, 2017 11:00 AM To: SULLIVAN, BRYAN L <bs3131 at att.com<mailto:bs3131 at att.com>> Cc: Christopher Donley (Chris) <Christopher.Donley at huawei.com<mailto:Christopher.Donley at huawei.com>>; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke <eaw at cisco.com<mailto:eaw at cisco.com>> Subject: Re: [onap-tsc] Updated TSC Charter Totally agree that gerrit can provide info on reviews, and that documentation and test code contributions simply show up as patches in whichever project they are contributed to. Do you see contributions to architecture coming via reviews? Ed On Wed, Apr 19, 2017 at 10:56 AM, SULLIVAN, BRYAN L <bs3131 at att.com<mailto:bs3131 at att.com>> wrote: Gerrit can also provide info on reviews, documentation contributions, etc. Tests and project infra I assume you could class as code, but these other types of contributions are also tracked by gerrit. Thanks, Bryan Sullivan | AT&T From: Ed Warnicke [mailto:hagbard at gmail.com<mailto:[email protected]>] Sent: Wednesday, April 19, 2017 10:50 AM To: SULLIVAN, BRYAN L <bs3131 at att.com<mailto:bs3131 at att.com>> Cc: Christopher Donley (Chris) <Christopher.Donley at huawei.com<mailto:Christopher.Donley at huawei.com>>; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>; Ed Warnicke <eaw at cisco.com<mailto:eaw at cisco.com>> Subject: Re: [onap-tsc] Updated TSC Charter Brian, How would one be able to point to demonstration of meritocratic contribution for non-code contribution for the purpose of committer promotion? For code contribution (and test case automation, which also then turns out to be code) one can point to the gerrit history. For these other kinds of contribution, what would be the analog demonstration? Ed On Wed, Apr 19, 2017 at 10:12 AM, SULLIVAN, BRYAN L <bs3131 at att.com<mailto:bs3131 at att.com>> wrote: Chris, Not sure I can post to the TSC list, but here are some comments in the draft: ? Each project will have its own code repositories (one or multiple),? o The concept of an umbrella project may address this, but that?s an overhead that should be optional. It may be more effective in some cases for projects just to have multiple repos. ? A Contributor is someone who contributes code or other artifacts to a project, and reviews the contributions of others. Contributors are not necessarily from Member companies. o We should encourage and recognize all forms of contribution, especially reviews. IMO contributors may provide *no* code but still contribute valuable advice on architecture, quality, testability, or other contributions of a non-code/artifact nature. ? Committer rights for a project are earned via code contribution ? o The potential pool of committers should go beyond just code contribution, given the merit of their other types of contributions ? (description of Incubation phase) Project has resources, but is recognized to be in early stages of development, having yet to achieve a MVP (Minimum Viable Product) that is (or can be) used in production environments. o Clarification as to what an MVP is as the target for the end of the incubation phase. ? Other editorial items Thanks, Bryan Sullivan | AT&T From: onap-tsc-bounces at lists.onap.org<mailto:onap-tsc-bounces at lists.onap.org> [mailto:onap-tsc-bounces at lists.onap.org<mailto:[email protected]>] On Behalf Of Christopher Donley (Chris) Sent: Wednesday, April 19, 2017 8:45 AM To: onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Cc: Ed Warnicke <eaw at cisco.com<mailto:eaw at cisco.com>> Subject: [onap-tsc] Updated TSC Charter Dear TSC, On behalf of the Charter drafting team, please find attached an updated version of the TSC Charter incorporating your suggestions and feedback from the last review. We have attempted to highlight the open issues that need a decision from the TSC. We are sending this draft with the intention that you review it in preparation for discussion and voting during our next TSC meeting. Chris, Steve, Ed, Lingli, Alla, and Phil _______________________________________________ ONAP-TSC mailing list ONAP-TSC at lists.onap.org<mailto:ONAP-TSC at lists.onap.org> https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=p0kzAvQDjXsrgQPIbU8s2Jv4A-H7H4aAbsbfuneN4Rg&s=vKRHTwaZCMn5ytWOCvgd5Lh-5iID3MW7HnGXLUdQlEI&e=> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-tsc/attachments/20170419/1dc164d7/attachment-0001.html>
