I think we are in agreement :) Ed
On Wed, Apr 19, 2017 at 1:15 PM, SULLIVAN, BRYAN L <bs3131 at att.com> wrote: > 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:hagbard at gmail.com] > *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> > 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] > *Sent:* Wednesday, April 19, 2017 11:00 AM > > > *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 > > > > 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> > 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] > *Sent:* Wednesday, April 19, 2017 10:50 AM > *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 > > > > 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> > 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@ > lists.onap.org] *On Behalf Of *Christopher Donley (Chris) > *Sent:* Wednesday, April 19, 2017 8:45 AM > *To:* onap-tsc at lists.onap.org > *Cc:* Ed Warnicke <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 > 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/47756efb/attachment-0001.html>
