I saw FLINK has a weekly update, this might be a useful way to let people know more about what's happening.
On Wed, Mar 28, 2018 at 10:10 AM, Michael Mior <[email protected]> wrote: > 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 > > >>>> > > >>>> > > >> > > >> > > > > > > > > > > > > > > > > > -- ~~~~~~~~~~~~~~~ no mistakes ~~~~~~~~~~~~~~~~~~
