You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@echarts.apache.org by Wenli Zhang <ov...@gmail.com> on 2018/11/04 12:15:09 UTC
Criteria for new ECharts committers
Hi all,
As you can see, we have several new contributors making PRs for our project.
And here we'd like to discuss what criteria is requested for one to become
a committer.
Here are some of my suggestions to start with:
1. We can set a minimum number for required PRs merged or issues
contributed. And we need to discuss the amount for them. How about 3 merged
PRs and 10 issues?
As for the definition of *issues contributed*, I think they should report
to us those issues that they think they've helped or made a progress, and
let us judge.
2. I'd suggest candidates send an email for application (maybe to the
private mailing list) and mention the links of their PRs or solved issues
or other contributions (like document fixing, suggestions and etc.). If you
guys agree on this, we shall put a notice about the details on our website
or GitHub about how to apply.
3. The quality is even more important, so this should probably also be
assessed by us.
4. Another requirement I think necessary is the commitment to contribute,
which may be in the form of making more PRs or fixing document errors, or
answering issue problems.
5. After an offline discussion with Dave, Shen Yi and Su Shuang, we think
it is necessary to require those new committers to make PR before their
commits are merged. It's a safer way to make sure our code is at its best
state.
Please feel free to share your opinions on this topic!
And looking forward to having new committers. :)
Zhang Wenli
http://zhangwenli.com
Re: Criteria for new ECharts committers
Posted by Dave Fisher <da...@comcast.net>.
Hi -
> On Nov 7, 2018, at 1:32 AM, SHUANG SU <su...@gmail.com> wrote:
>
>> 1. We can set a minimum number for required PRs merged or issues
> contributed. And we need to discuss the amount for them. How about 3 merged
> PRs and 10 issues?
> As for the definition of *issues contributed*, I think they should report
> to us those issues that they think they've helped or made a progress, and
> let us judge.
>
> Different issues require different efforts and different level of tech
> knowledge & skills (about this domain and this project). A PR can be
> as simple as changing a typo of a comment, or as complex as modifying
> the underlying framework of the program. So I am afraid it is not a good
> idea
> to make an accurate number of PR and issues as a standard of becoming a
> committer.
> I agree that a candidate need to send application, and the PMC will
> make discussion and investigate that by the historic contribution and other
> factors.
The PPMC needs to look for contributions, we should not take applications.
There is one way that a contributor can indicate that they wish to be a committer. That is submitting an Individual Contributors Agreement and indicating that they want to be part of ECharts.
>
>> 5. After an offline discussion with Dave, Shen Yi and Su Shuang, we think
> it is necessary to require those new committers to make PR before their
> commits are merged. It's a safer way to make sure our code is at its best
> state.
>
> I agree with that the PR rule, at least in the current stage. Because
> currently
> in practice, the quality of the commits is not good enough to remit the
> code review.
> And a code review makes others think about an issue, that always
> brings some
> issues that not thought of before.
The quality of PRs should be an indication about whether or not a contributor is ready to be a committer.
Be ready to consider non-code / documentation / translation help as ways for contributors to gain merit.
Regards,
Dave
>
>
> ------------------------------
> Su Shuang (100pah)
> ------------------------------
>
>
>
> On Wed, 7 Nov 2018 at 16:29, Wenli Zhang <ov...@gmail.com> wrote:
>
>> Thank you Kevin! That's really good advice.
>>
>> What do other guys think? Please let me know. :)
>>
>> Zhang Wenli
>> http://zhangwenli.com
>>
>>
>> On Wed, Nov 7, 2018 at 3:53 AM Kevin A. McGrail <km...@apache.org>
>> wrote:
>>
>>> I would recommend you look towards what you can do to:
>>>
>>> A) encourage people who are not coders to contribute. Right now, you
>> only
>>> cover coders. Bug management, graphics, documentation, testing, etc. are
>>> all necessary.
>>>
>>> B) Consider a lower bar towards entry. For example, the SVN project
>> allows
>>> anyone who is a committer on another project to commit. I'm not saying
>>> that broad but right now, I think you want to encourage people who have
>>> high quality but low volume commits still.
>>>
>>> Regards,
>>> KAM
>>>
>>>
>>> --
>>> Kevin A. McGrail
>>> VP Fundraising, Apache Software Foundation
>>> Chair Emeritus Apache SpamAssassin Project
>>> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>>>
>>>
>>> On Sun, Nov 4, 2018 at 7:15 AM Wenli Zhang <ov...@gmail.com>
>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> As you can see, we have several new contributors making PRs for our
>>>> project.
>>>> And here we'd like to discuss what criteria is requested for one to
>>> become
>>>> a committer.
>>>>
>>>> Here are some of my suggestions to start with:
>>>>
>>>> 1. We can set a minimum number for required PRs merged or issues
>>>> contributed. And we need to discuss the amount for them. How about 3
>>> merged
>>>> PRs and 10 issues?
>>>> As for the definition of *issues contributed*, I think they should
>> report
>>>> to us those issues that they think they've helped or made a progress,
>> and
>>>> let us judge.
>>>>
>>>> 2. I'd suggest candidates send an email for application (maybe to the
>>>> private mailing list) and mention the links of their PRs or solved
>> issues
>>>> or other contributions (like document fixing, suggestions and etc.). If
>>> you
>>>> guys agree on this, we shall put a notice about the details on our
>>> website
>>>> or GitHub about how to apply.
>>>>
>>>> 3. The quality is even more important, so this should probably also be
>>>> assessed by us.
>>>>
>>>> 4. Another requirement I think necessary is the commitment to
>> contribute,
>>>> which may be in the form of making more PRs or fixing document errors,
>> or
>>>> answering issue problems.
>>>>
>>>> 5. After an offline discussion with Dave, Shen Yi and Su Shuang, we
>> think
>>>> it is necessary to require those new committers to make PR before their
>>>> commits are merged. It's a safer way to make sure our code is at its
>> best
>>>> state.
>>>>
>>>> Please feel free to share your opinions on this topic!
>>>> And looking forward to having new committers. :)
>>>>
>>>> Zhang Wenli
>>>> http://zhangwenli.com
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@echarts.apache.org
For additional commands, e-mail: dev-help@echarts.apache.org
Re: Criteria for new ECharts committers
Posted by SHUANG SU <su...@gmail.com>.
> 1. We can set a minimum number for required PRs merged or issues
contributed. And we need to discuss the amount for them. How about 3 merged
PRs and 10 issues?
As for the definition of *issues contributed*, I think they should report
to us those issues that they think they've helped or made a progress, and
let us judge.
Different issues require different efforts and different level of tech
knowledge & skills (about this domain and this project). A PR can be
as simple as changing a typo of a comment, or as complex as modifying
the underlying framework of the program. So I am afraid it is not a good
idea
to make an accurate number of PR and issues as a standard of becoming a
committer.
I agree that a candidate need to send application, and the PMC will
make discussion and investigate that by the historic contribution and other
factors.
> 5. After an offline discussion with Dave, Shen Yi and Su Shuang, we think
it is necessary to require those new committers to make PR before their
commits are merged. It's a safer way to make sure our code is at its best
state.
I agree with that the PR rule, at least in the current stage. Because
currently
in practice, the quality of the commits is not good enough to remit the
code review.
And a code review makes others think about an issue, that always
brings some
issues that not thought of before.
------------------------------
Su Shuang (100pah)
------------------------------
On Wed, 7 Nov 2018 at 16:29, Wenli Zhang <ov...@gmail.com> wrote:
> Thank you Kevin! That's really good advice.
>
> What do other guys think? Please let me know. :)
>
> Zhang Wenli
> http://zhangwenli.com
>
>
> On Wed, Nov 7, 2018 at 3:53 AM Kevin A. McGrail <km...@apache.org>
> wrote:
>
> > I would recommend you look towards what you can do to:
> >
> > A) encourage people who are not coders to contribute. Right now, you
> only
> > cover coders. Bug management, graphics, documentation, testing, etc. are
> > all necessary.
> >
> > B) Consider a lower bar towards entry. For example, the SVN project
> allows
> > anyone who is a committer on another project to commit. I'm not saying
> > that broad but right now, I think you want to encourage people who have
> > high quality but low volume commits still.
> >
> > Regards,
> > KAM
> >
> >
> > --
> > Kevin A. McGrail
> > VP Fundraising, Apache Software Foundation
> > Chair Emeritus Apache SpamAssassin Project
> > https://www.linkedin.com/in/kmcgrail - 703.798.0171
> >
> >
> > On Sun, Nov 4, 2018 at 7:15 AM Wenli Zhang <ov...@gmail.com>
> wrote:
> >
> > > Hi all,
> > >
> > > As you can see, we have several new contributors making PRs for our
> > > project.
> > > And here we'd like to discuss what criteria is requested for one to
> > become
> > > a committer.
> > >
> > > Here are some of my suggestions to start with:
> > >
> > > 1. We can set a minimum number for required PRs merged or issues
> > > contributed. And we need to discuss the amount for them. How about 3
> > merged
> > > PRs and 10 issues?
> > > As for the definition of *issues contributed*, I think they should
> report
> > > to us those issues that they think they've helped or made a progress,
> and
> > > let us judge.
> > >
> > > 2. I'd suggest candidates send an email for application (maybe to the
> > > private mailing list) and mention the links of their PRs or solved
> issues
> > > or other contributions (like document fixing, suggestions and etc.). If
> > you
> > > guys agree on this, we shall put a notice about the details on our
> > website
> > > or GitHub about how to apply.
> > >
> > > 3. The quality is even more important, so this should probably also be
> > > assessed by us.
> > >
> > > 4. Another requirement I think necessary is the commitment to
> contribute,
> > > which may be in the form of making more PRs or fixing document errors,
> or
> > > answering issue problems.
> > >
> > > 5. After an offline discussion with Dave, Shen Yi and Su Shuang, we
> think
> > > it is necessary to require those new committers to make PR before their
> > > commits are merged. It's a safer way to make sure our code is at its
> best
> > > state.
> > >
> > > Please feel free to share your opinions on this topic!
> > > And looking forward to having new committers. :)
> > >
> > > Zhang Wenli
> > > http://zhangwenli.com
> > >
> >
>
Re: Criteria for new ECharts committers
Posted by Wenli Zhang <ov...@gmail.com>.
Thank you Kevin! That's really good advice.
What do other guys think? Please let me know. :)
Zhang Wenli
http://zhangwenli.com
On Wed, Nov 7, 2018 at 3:53 AM Kevin A. McGrail <km...@apache.org> wrote:
> I would recommend you look towards what you can do to:
>
> A) encourage people who are not coders to contribute. Right now, you only
> cover coders. Bug management, graphics, documentation, testing, etc. are
> all necessary.
>
> B) Consider a lower bar towards entry. For example, the SVN project allows
> anyone who is a committer on another project to commit. I'm not saying
> that broad but right now, I think you want to encourage people who have
> high quality but low volume commits still.
>
> Regards,
> KAM
>
>
> --
> Kevin A. McGrail
> VP Fundraising, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>
>
> On Sun, Nov 4, 2018 at 7:15 AM Wenli Zhang <ov...@gmail.com> wrote:
>
> > Hi all,
> >
> > As you can see, we have several new contributors making PRs for our
> > project.
> > And here we'd like to discuss what criteria is requested for one to
> become
> > a committer.
> >
> > Here are some of my suggestions to start with:
> >
> > 1. We can set a minimum number for required PRs merged or issues
> > contributed. And we need to discuss the amount for them. How about 3
> merged
> > PRs and 10 issues?
> > As for the definition of *issues contributed*, I think they should report
> > to us those issues that they think they've helped or made a progress, and
> > let us judge.
> >
> > 2. I'd suggest candidates send an email for application (maybe to the
> > private mailing list) and mention the links of their PRs or solved issues
> > or other contributions (like document fixing, suggestions and etc.). If
> you
> > guys agree on this, we shall put a notice about the details on our
> website
> > or GitHub about how to apply.
> >
> > 3. The quality is even more important, so this should probably also be
> > assessed by us.
> >
> > 4. Another requirement I think necessary is the commitment to contribute,
> > which may be in the form of making more PRs or fixing document errors, or
> > answering issue problems.
> >
> > 5. After an offline discussion with Dave, Shen Yi and Su Shuang, we think
> > it is necessary to require those new committers to make PR before their
> > commits are merged. It's a safer way to make sure our code is at its best
> > state.
> >
> > Please feel free to share your opinions on this topic!
> > And looking forward to having new committers. :)
> >
> > Zhang Wenli
> > http://zhangwenli.com
> >
>
Re: Criteria for new ECharts committers
Posted by "Kevin A. McGrail" <km...@apache.org>.
I would recommend you look towards what you can do to:
A) encourage people who are not coders to contribute. Right now, you only
cover coders. Bug management, graphics, documentation, testing, etc. are
all necessary.
B) Consider a lower bar towards entry. For example, the SVN project allows
anyone who is a committer on another project to commit. I'm not saying
that broad but right now, I think you want to encourage people who have
high quality but low volume commits still.
Regards,
KAM
--
Kevin A. McGrail
VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Sun, Nov 4, 2018 at 7:15 AM Wenli Zhang <ov...@gmail.com> wrote:
> Hi all,
>
> As you can see, we have several new contributors making PRs for our
> project.
> And here we'd like to discuss what criteria is requested for one to become
> a committer.
>
> Here are some of my suggestions to start with:
>
> 1. We can set a minimum number for required PRs merged or issues
> contributed. And we need to discuss the amount for them. How about 3 merged
> PRs and 10 issues?
> As for the definition of *issues contributed*, I think they should report
> to us those issues that they think they've helped or made a progress, and
> let us judge.
>
> 2. I'd suggest candidates send an email for application (maybe to the
> private mailing list) and mention the links of their PRs or solved issues
> or other contributions (like document fixing, suggestions and etc.). If you
> guys agree on this, we shall put a notice about the details on our website
> or GitHub about how to apply.
>
> 3. The quality is even more important, so this should probably also be
> assessed by us.
>
> 4. Another requirement I think necessary is the commitment to contribute,
> which may be in the form of making more PRs or fixing document errors, or
> answering issue problems.
>
> 5. After an offline discussion with Dave, Shen Yi and Su Shuang, we think
> it is necessary to require those new committers to make PR before their
> commits are merged. It's a safer way to make sure our code is at its best
> state.
>
> Please feel free to share your opinions on this topic!
> And looking forward to having new committers. :)
>
> Zhang Wenli
> http://zhangwenli.com
>