I wasn't suggesting that people submitting issues or PRs do the assigning. Aside from time, my biggest challenge to contributing more is not knowing who to ping since my own expertise is fairly limited. My thinking behind owners is just that it would make it clear who has the expertise in certain areas. But since the consensus seems to be against it, I'm fine with going with any alternative that works.
-- Michael Mior [email protected] 2018-03-27 21:41 GMT-04:00 Julian Hyde <[email protected]>: > I agree with Jesus. I think it’s more important to deal with the > management, and have a person to handle incoming PRs, than to try to break > the product into well-defined components. > > "Component owners” are problematic because it’s not always clear > (especially to contributors) which parts of the code a given PR touches. A > vertical feature such as CREATE TYPE (CALCITE-2045) or authorization > (CALCITE-2194) will often cut through everything. > > In contrast, a coordinator would just assign PRs to people with the > necessary expertise, not do the reviewing. The load on them would be light > enough that they might volunteer to do it in some future month, which is > good, because we don’t want to burn anyone out. > > Julian > > > > On Mar 27, 2018, at 4:38 PM, Jesus Camacho Rodriguez < > [email protected]> wrote: > > > > IMO the most important task is to stay on top of the issues and PRs, > > I am not so concerned about the other project management tasks > > since it is easier to do them collaboratively. > > > > I think we do not need owners for components, as it will not help the > > project in any way. If an owner does not review some PRs, what are > > we going to do? Effectively, we cannot force him/her to do it timely, > > and at the same time, we do not want to hold commits to the project > > till the owner decides to review the PR. > > > > Committers are more familiar with each other's work so we (the > > committers) could try to proactively monitor the mailing list for > > new issues and help contributors by reviewing or pinging the right > > reviewer for each of them. Ultimately, it is our responsibility > > as a community to commit those patches and keep the project > > moving forward. This means that we may need to step up and > > review a certain patch as well as we can, even if we are less > > familiar with a certain module. > > > > -Jesús > > > > > > > > On 3/27/18, 2:33 PM, "F21" <[email protected]> wrote: > > > > Hey everyone, > > > > I am happy to take ownership of the Go avatica client. I am currently > > quite busy, but I hope to test it against the latest version of > avatica > > released a couple of weeks ago and see if we can make a release for > it. > > > > Francis > > > > On 28/03/2018 6:27 AM, Shuyi Chen wrote: > >> Hi Julian and Michael, > >> > >> Thanks a lot for starting the discussion. I think the ownership model > is a > >> good idea, and has been used by other open source communities, and we > can > >> further break down core into e.g. sql parser, sql validator, relational > >> algebra, planner, JSON model, runtime and etc,. Also, we need to add > the > >> 'server' module into the JIRA component list for DDLs. And I think > adding > >> component in the PR title will help owner to filter and identify issues > >> quickly, also I think we can use a template to enforce a more detail PR > >> description, so the reviewer can better understand the context and > review > >> the code. > >> > >> I have some knowledge in sql parser, JSON model, relational algebra and > >> planner, and is currently working on the server module to add the > >> type/library/function DDLs. I can definitely help on answering > questions on > >> mailing list, reviewing code and contributing PRs for these components. > >> Also, I am definitely interested in learning and helping more on > committing > >> code and doing releases as well. > >> > >> Cheers > >> Shuyi > >> > >> > >> On Tue, Mar 27, 2018 at 9:51 AM, Michael Mior <[email protected]> > wrote: > >> > >>> Thanks for starting the discussion Julian. I suggested at some point > in the > >>> past that we figure out people who are willing to take ownership over > >>> certain components of Calcite. It seems like this would at least be a > start > >>> to staying on top of PRs and issues. However, we would probably have to > >>> segment core practically for this to help. > >>> > >>> Another thing that comes to mind is staying on top of updates to > >>> dependencies. If people are owning certain components, hopefully they > would > >>> also be willing to do a quick check around release time to see if new > >>> versions of dependencies for that component have been released and > test and > >>> update if possible. > >>> > >>> Then there's also more administrative tasks such as making releases and > >>> ensuring a good flow of new committers and PMC members. Anything else > I'm > >>> missing? > >>> > >>> Cheers, > >>> -- > >>> Michael Mior > >>> [email protected] > >>> > >>> 2018-03-27 12:40 GMT-04:00 Julian Hyde <[email protected]>: > >>> > >>>> I’m not working full-time on Calcite anymore. But this project still > >>> needs > >>>> regular — daily — work to stay on top of contributions. If there’s > only > >>> one > >>>> person doing the work then one will is likely to become zero. > >>>> > >>>> Let’s come up with a plan — with some commitments — for how this work > >>> will > >>>> get done. > >>>> > >>>> Julian > >>>> > >>>> > >> > >> > > > > > > > > > >
