You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beam.apache.org by Aviem Zur <av...@gmail.com> on 2017/04/22 14:31:18 UTC
[DISCUSSION] Encouraging more contributions
Hi all,
I wanted to start a discussion about actions we can take to encourage more
contributions to the project.
A few points I've been thinking of:
1. Have people unassign themselves from issues they're not actively working
on.
2. Have the community engage more in triage, improving tickets descriptions
and raising concerns.
3. Clean house - apply (2) to currently open issues (over 800). Perhaps
some can be closed.
Thoughts? Ideas?
Re: [DISCUSSION] Encouraging more contributions
Posted by tarush grover <ta...@gmail.com>.
Hi All,
I can take few things. I have planned to contribute towards beam SQL DSL
but members can assign more things and will be happy to contribute towards
those tasks.
Regards,
Tarush
On Sat, 22 Apr 2017 at 8:40 PM, Mingmin Xu <mi...@gmail.com> wrote:
> Good point, could also disable the auto assignment when creating JIRA
> ticket. Now it goes to component leader directly.
>
> Sent from my iPhone
>
> > On Apr 22, 2017, at 7:34 AM, Ted Yu <yu...@gmail.com> wrote:
> >
> > +1
> >
> >> On Sat, Apr 22, 2017 at 7:31 AM, Aviem Zur <av...@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> I wanted to start a discussion about actions we can take to encourage
> more
> >> contributions to the project.
> >>
> >> A few points I've been thinking of:
> >>
> >> 1. Have people unassign themselves from issues they're not actively
> working
> >> on.
> >> 2. Have the community engage more in triage, improving tickets
> descriptions
> >> and raising concerns.
> >> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
> >> some can be closed.
> >>
> >> Thoughts? Ideas?
> >>
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Mingmin Xu <mi...@gmail.com>.
Good point, could also disable the auto assignment when creating JIRA ticket. Now it goes to component leader directly.
Sent from my iPhone
> On Apr 22, 2017, at 7:34 AM, Ted Yu <yu...@gmail.com> wrote:
>
> +1
>
>> On Sat, Apr 22, 2017 at 7:31 AM, Aviem Zur <av...@gmail.com> wrote:
>>
>> Hi all,
>>
>> I wanted to start a discussion about actions we can take to encourage more
>> contributions to the project.
>>
>> A few points I've been thinking of:
>>
>> 1. Have people unassign themselves from issues they're not actively working
>> on.
>> 2. Have the community engage more in triage, improving tickets descriptions
>> and raising concerns.
>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>> some can be closed.
>>
>> Thoughts? Ideas?
>>
Re: [DISCUSSION] Encouraging more contributions
Posted by Ted Yu <yu...@gmail.com>.
+1
On Sat, Apr 22, 2017 at 7:31 AM, Aviem Zur <av...@gmail.com> wrote:
> Hi all,
>
> I wanted to start a discussion about actions we can take to encourage more
> contributions to the project.
>
> A few points I've been thinking of:
>
> 1. Have people unassign themselves from issues they're not actively working
> on.
> 2. Have the community engage more in triage, improving tickets descriptions
> and raising concerns.
> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
> some can be closed.
>
> Thoughts? Ideas?
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Etienne Chauchot <ec...@gmail.com>.
Hi Stephen,
Yes, it is a good answer, the doc "Authoring I/O Transforms - Overview"
(https://beam.apache.org/documentation/io/authoring-overview/) is
exactly what I had in mind.
IMHO, writing this kind of docs (beam contributor oriented) for all the
key concepts, and stored at one only (searchable, easy access) place
would be awsome!
Etienne
Le 25/04/2017 � 02:54, Stephen Sisk a �crit :
> general +1 to the concept, including driving down
> assigned-but-not-actually-being-worked-on items.
>
> I also really like the idea of having a mentor on tickets.
>
> Etienne, Re: specific help for I/Os - is the I/O Authoring docs not a good
> answer? https://beam.apache.org/documentation/io/io-toc/ (or perhaps we
> need to update that somehow)
>
> S
>
> On Mon, Apr 24, 2017 at 5:45 PM Sourabh Bajaj
> <so...@google.com.invalid> wrote:
>
>> For 6. I think having them in one page on the website where we can find the
>> design docs more easily would be great.
>>
>> 7. For low-hanging-fruit, one thing I really liked from some Mozilla
>> projects was assigning a mentor on the ticket. Someone you can reach out to
>> if you have questions. I think this makes the entry barrier really low for
>> first time contributors who might feel intimidated asking questions
>> completely in public.
>>
>> On Mon, Apr 24, 2017 at 10:06 AM Kenneth Knowles <kl...@google.com.invalid>
>> wrote:
>>
>>> I like the subject Etienne has brought up, and will give it a number in
>>> this list :-)
>>>
>>> 6. Have more technical reference docs (not just workspace set up) for
>>> contributors.
>>>
>>> I think this overlaps a lot with a prior discussion about where to
>> collect
>>> design proposals [1]. Design docs used to be just dropped into a public
>>> folder, but that got disorganized. And that thread was about work in
>>> progress, so JIRA was a good place for details after a dev@ thread
>> agrees
>>> on a proposal. At this point, the designs are pretty solid conceptually
>> or
>>> even implemented and we could start to build out deeper technical bits on
>>> the web site, or at least some place that people can find it. We do have
>>> the Testing Guide and the PTransform Style Guide and somewhere near there
>>> we could have deeper references. I think we need a broader vision for the
>>> "table of contents" here.
>>>
>>> For my docs (triggers, lateness, runner API, side inputs, state, coders)
>> I
>>> haven't had time, but I do intend to both translate from GDoc to some
>> other
>>> format and also rewrite versions for users where appropriate. Probably
>> this
>>> will mean coming up with that table of contents.
>>>
>>> Kenn
>>>
>>> [1]
>>>
>>>
>> https://lists.apache.org/thread.html/%3C6bc60c88-cf91-4fff-eae6-fea6ee06f662@nanthrax.net%3E
>>>
>>> On Mon, Apr 24, 2017 at 9:33 AM, Neelesh Salian <
>> neeleshssalian@gmail.com>
>>> wrote:
>>>
>>>> Agreed. I have some old JIRAs that I am cleaning up.
>>>>
>>>> Thank you for bringing this up.
>>>>
>>>> On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofr� <jb@nanthrax.net
>>>> wrote:
>>>>
>>>>> Same also for Slack, github comments, etc.
>>>>>
>>>>> From a Apache perspective, it should happen on the mailing list,
>>>>> eventually referencing a central wiki/faq/whatever.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 04/24/2017 06:23 PM, Mingmin Xu wrote:
>>>>>
>>>>>> many design documents are mixed in maillist, jira comments, it would
>>> be
>>>> a
>>>>>> big help to put them in a centralized list. Also I would expect more
>>>>>> wiki/blogs to provide in-depth analysis, like the translation from
>>>>>> pipeline
>>>>>> to runner specified topology, window/trigger implementation. Without
>>>> these
>>>>>> knowledge, it's hard to touch the core concepts.
>>>>>>
>>>>>> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofr� <
>>> jb@nanthrax.net>
>>>>>> wrote:
>>>>>>
>>>>>> Got it. By experience on other Apache projects, it's really hard to
>>>>>>> maintain ;)
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
>>>>>>>
>>>>>>> Hi JB,
>>>>>>>> I was proposing a FAQ (or another form), not something about IDE
>>>> setup.
>>>>>>>> The FAQ
>>>>>>>> could group in the same place Q/A like for example "what is a
>>> source,
>>>>>>>> how
>>>>>>>> do I
>>>>>>>> use it to implement an IO"
>>>>>>>>
>>>>>>>> Etienne
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 24/04/2017 � 14:19, Jean-Baptiste Onofr� a �crit :
>>>>>>>>
>>>>>>>> Hi Etienne,
>>>>>>>>> What about the contribution guide ? I think it's covered in the
>>>>>>>>> IntelliJ
>>>>>>>>> and
>>>>>>>>> Eclipse setup sections.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>> I definitely agree with everything that is said in this thread.
>>>>>>>>>>
>>>>>>>>>> I might suggest another good to have:
>>>>>>>>>>
>>>>>>>>>> to ease the work of a new contributor, it would be nice to have
>>> some
>>>>>>>>>> sort of
>>>>>>>>>> programming guide but not oriented to pipeline writers but to
>>>>>>>>>> sdk/runner/io/...
>>>>>>>>>> writers.
>>>>>>>>>>
>>>>>>>>>> I know that new contributors have the docs available in the
>> google
>>>>>>>>>> drive, the
>>>>>>>>>> ML, the code base, and the availability of beamers, but maybe
>>> having
>>>>>>>>>> key points
>>>>>>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for
>>>>>>>>>> example)
>>>>>>>>>> would be
>>>>>>>>>> interesting.
>>>>>>>>>>
>>>>>>>>>> Best,
>>>>>>>>>>
>>>>>>>>>> Etienne
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Le 24/04/2017 � 09:14, Jean-Baptiste Onofr� a �crit :
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>> I think we already tag the newbie jira ("low hanging fruit"
>> ;)).
>>>>>>>>>>> Good idea for domain of interest/concept.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>>>>>>>>>
>>>>>>>>>>> Might I suggest adding tags to projects based on area of
>>> intetest,
>>>>>>>>>>>> concept
>>>>>>>>>>>> and if it's a good "first bug".
>>>>>>>>>>>>
>>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>>
>>>>>>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org>
>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Have people unassign themselves from issues they're not
>>>> actively
>>>>>>>>>>>>>> working on.
>>>>>>>>>>>>>> 2. Have the community engage more in triage, improving
>> tickets
>>>>>>>>>>>>>> descriptions and raising concerns.
>>>>>>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over
>>> 800).
>>>>>>>>>>>>>> Perhaps
>>>>>>>>>>>>>> some can be closed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> +1 on all three of these, and will do my part shortly!
>>>>>>>>>>>>> Also, it is worth noting that we have improved as a project
>> in
>>>>>>>>>>>>> tracking
>>>>>>>>>>>>> issues in the last 1-2 months. There are more resolved issues
>>>> than
>>>>>>>>>>>>> opened
>>>>>>>>>>>>> in this period, whereas in the past we'd have a hundred more
>>>> opened
>>>>>>>>>>>>> than
>>>>>>>>>>>>> resolved.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would also propose to not assign new Jira automatically:
>> now,
>>>> the
>>>>>>>>>>>>> Jira is
>>>>>>>>>>>>>
>>>>>>>>>>>>> automatically assigned to the Jira component leader.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Imagine a user discovering an issue and filing a new JIRA
>>> issue.
>>>>>>>>>>>>> It
>>>>>>>>>>>>> wouldn't be assigned to anyone, significantly reducing the
>>> chance
>>>>>>>>>>>>> somebody
>>>>>>>>>>>>> will actually help.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Of course, somebody could search for new issues periodically,
>>>> etc.
>>>>>>>>>>>>> -- but
>>>>>>>>>>>>> that just won't happen. The final outcome would be -- instead
>>> of
>>>> a
>>>>>>>>>>>>> lot of
>>>>>>>>>>>>> issues assigned to component leads, we'd have (much) more
>>>>>>>>>>>>> unassigned
>>>>>>>>>>>>> issues, which were *never* looked at. Assigning an issue just
>>>> sets
>>>>>>>>>>>>> a
>>>>>>>>>>>>> community expectation that a committer should look -- and it
>>> does
>>>>>>>>>>>>> help move
>>>>>>>>>>>>> things along!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think a better approach of addressing the current state
>> would
>>>> be
>>>>>>>>>>>>> increase
>>>>>>>>>>>>> the number of components / component leads. With more people
>>>>>>>>>>>>> involved and
>>>>>>>>>>>>> lower per-person load, I think we'd be more effective.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>> --
>>>>>>> Jean-Baptiste Onofr�
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofr�
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Neelesh S. Salian
>>>>
Re: [DISCUSSION] Encouraging more contributions
Posted by Stephen Sisk <si...@google.com.INVALID>.
general +1 to the concept, including driving down
assigned-but-not-actually-being-worked-on items.
I also really like the idea of having a mentor on tickets.
Etienne, Re: specific help for I/Os - is the I/O Authoring docs not a good
answer? https://beam.apache.org/documentation/io/io-toc/ (or perhaps we
need to update that somehow)
S
On Mon, Apr 24, 2017 at 5:45 PM Sourabh Bajaj
<so...@google.com.invalid> wrote:
> For 6. I think having them in one page on the website where we can find the
> design docs more easily would be great.
>
> 7. For low-hanging-fruit, one thing I really liked from some Mozilla
> projects was assigning a mentor on the ticket. Someone you can reach out to
> if you have questions. I think this makes the entry barrier really low for
> first time contributors who might feel intimidated asking questions
> completely in public.
>
> On Mon, Apr 24, 2017 at 10:06 AM Kenneth Knowles <kl...@google.com.invalid>
> wrote:
>
> > I like the subject Etienne has brought up, and will give it a number in
> > this list :-)
> >
> > 6. Have more technical reference docs (not just workspace set up) for
> > contributors.
> >
> > I think this overlaps a lot with a prior discussion about where to
> collect
> > design proposals [1]. Design docs used to be just dropped into a public
> > folder, but that got disorganized. And that thread was about work in
> > progress, so JIRA was a good place for details after a dev@ thread
> agrees
> > on a proposal. At this point, the designs are pretty solid conceptually
> or
> > even implemented and we could start to build out deeper technical bits on
> > the web site, or at least some place that people can find it. We do have
> > the Testing Guide and the PTransform Style Guide and somewhere near there
> > we could have deeper references. I think we need a broader vision for the
> > "table of contents" here.
> >
> > For my docs (triggers, lateness, runner API, side inputs, state, coders)
> I
> > haven't had time, but I do intend to both translate from GDoc to some
> other
> > format and also rewrite versions for users where appropriate. Probably
> this
> > will mean coming up with that table of contents.
> >
> > Kenn
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/%3C6bc60c88-cf91-4fff-eae6-fea6ee06f662@nanthrax.net%3E
> >
> >
> > On Mon, Apr 24, 2017 at 9:33 AM, Neelesh Salian <
> neeleshssalian@gmail.com>
> > wrote:
> >
> > > Agreed. I have some old JIRAs that I am cleaning up.
> > >
> > > Thank you for bringing this up.
> > >
> > > On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofré <jb@nanthrax.net
> >
> > > wrote:
> > >
> > > > Same also for Slack, github comments, etc.
> > > >
> > > > From a Apache perspective, it should happen on the mailing list,
> > > > eventually referencing a central wiki/faq/whatever.
> > > >
> > > > Regards
> > > > JB
> > > >
> > > >
> > > > On 04/24/2017 06:23 PM, Mingmin Xu wrote:
> > > >
> > > >> many design documents are mixed in maillist, jira comments, it would
> > be
> > > a
> > > >> big help to put them in a centralized list. Also I would expect more
> > > >> wiki/blogs to provide in-depth analysis, like the translation from
> > > >> pipeline
> > > >> to runner specified topology, window/trigger implementation. Without
> > > these
> > > >> knowledge, it's hard to touch the core concepts.
> > > >>
> > > >> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofré <
> > jb@nanthrax.net>
> > > >> wrote:
> > > >>
> > > >> Got it. By experience on other Apache projects, it's really hard to
> > > >>> maintain ;)
> > > >>>
> > > >>> Regards
> > > >>> JB
> > > >>>
> > > >>>
> > > >>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
> > > >>>
> > > >>> Hi JB,
> > > >>>>
> > > >>>> I was proposing a FAQ (or another form), not something about IDE
> > > setup.
> > > >>>> The FAQ
> > > >>>> could group in the same place Q/A like for example "what is a
> > source,
> > > >>>> how
> > > >>>> do I
> > > >>>> use it to implement an IO"
> > > >>>>
> > > >>>> Etienne
> > > >>>>
> > > >>>>
> > > >>>> Le 24/04/2017 à 14:19, Jean-Baptiste Onofré a écrit :
> > > >>>>
> > > >>>> Hi Etienne,
> > > >>>>>
> > > >>>>> What about the contribution guide ? I think it's covered in the
> > > >>>>> IntelliJ
> > > >>>>> and
> > > >>>>> Eclipse setup sections.
> > > >>>>>
> > > >>>>> Regards
> > > >>>>> JB
> > > >>>>>
> > > >>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
> > > >>>>>
> > > >>>>> Hi all,
> > > >>>>>>
> > > >>>>>> I definitely agree with everything that is said in this thread.
> > > >>>>>>
> > > >>>>>> I might suggest another good to have:
> > > >>>>>>
> > > >>>>>> to ease the work of a new contributor, it would be nice to have
> > some
> > > >>>>>> sort of
> > > >>>>>> programming guide but not oriented to pipeline writers but to
> > > >>>>>> sdk/runner/io/...
> > > >>>>>> writers.
> > > >>>>>>
> > > >>>>>> I know that new contributors have the docs available in the
> google
> > > >>>>>> drive, the
> > > >>>>>> ML, the code base, and the availability of beamers, but maybe
> > having
> > > >>>>>> key points
> > > >>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for
> > > >>>>>> example)
> > > >>>>>> would be
> > > >>>>>> interesting.
> > > >>>>>>
> > > >>>>>> Best,
> > > >>>>>>
> > > >>>>>> Etienne
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Le 24/04/2017 à 09:14, Jean-Baptiste Onofré a écrit :
> > > >>>>>>
> > > >>>>>> Hi,
> > > >>>>>>>
> > > >>>>>>> I think we already tag the newbie jira ("low hanging fruit"
> ;)).
> > > >>>>>>>
> > > >>>>>>> Good idea for domain of interest/concept.
> > > >>>>>>>
> > > >>>>>>> Regards
> > > >>>>>>> JB
> > > >>>>>>>
> > > >>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
> > > >>>>>>>
> > > >>>>>>> Might I suggest adding tags to projects based on area of
> > intetest,
> > > >>>>>>>> concept
> > > >>>>>>>> and if it's a good "first bug".
> > > >>>>>>>>
> > > >>>>>>>> Sent from my iPhone
> > > >>>>>>>>
> > > >>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org>
> > wrote:
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> 1. Have people unassign themselves from issues they're not
> > > actively
> > > >>>>>>>>>> working on.
> > > >>>>>>>>>> 2. Have the community engage more in triage, improving
> tickets
> > > >>>>>>>>>> descriptions and raising concerns.
> > > >>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over
> > 800).
> > > >>>>>>>>>> Perhaps
> > > >>>>>>>>>> some can be closed.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> +1 on all three of these, and will do my part shortly!
> > > >>>>>>>>>
> > > >>>>>>>>> Also, it is worth noting that we have improved as a project
> in
> > > >>>>>>>>> tracking
> > > >>>>>>>>> issues in the last 1-2 months. There are more resolved issues
> > > than
> > > >>>>>>>>> opened
> > > >>>>>>>>> in this period, whereas in the past we'd have a hundred more
> > > opened
> > > >>>>>>>>> than
> > > >>>>>>>>> resolved.
> > > >>>>>>>>>
> > > >>>>>>>>> I would also propose to not assign new Jira automatically:
> now,
> > > the
> > > >>>>>>>>> Jira is
> > > >>>>>>>>>
> > > >>>>>>>>> automatically assigned to the Jira component leader.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> Imagine a user discovering an issue and filing a new JIRA
> > issue.
> > > >>>>>>>>> It
> > > >>>>>>>>> wouldn't be assigned to anyone, significantly reducing the
> > chance
> > > >>>>>>>>> somebody
> > > >>>>>>>>> will actually help.
> > > >>>>>>>>>
> > > >>>>>>>>> Of course, somebody could search for new issues periodically,
> > > etc.
> > > >>>>>>>>> -- but
> > > >>>>>>>>> that just won't happen. The final outcome would be -- instead
> > of
> > > a
> > > >>>>>>>>> lot of
> > > >>>>>>>>> issues assigned to component leads, we'd have (much) more
> > > >>>>>>>>> unassigned
> > > >>>>>>>>> issues, which were *never* looked at. Assigning an issue just
> > > sets
> > > >>>>>>>>> a
> > > >>>>>>>>> community expectation that a committer should look -- and it
> > does
> > > >>>>>>>>> help move
> > > >>>>>>>>> things along!
> > > >>>>>>>>>
> > > >>>>>>>>> I think a better approach of addressing the current state
> would
> > > be
> > > >>>>>>>>> increase
> > > >>>>>>>>> the number of components / component leads. With more people
> > > >>>>>>>>> involved and
> > > >>>>>>>>> lower per-person load, I think we'd be more effective.
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>> --
> > > >>> Jean-Baptiste Onofré
> > > >>> jbonofre@apache.org
> > > >>> http://blog.nanthrax.net
> > > >>> Talend - http://www.talend.com
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > > --
> > > > Jean-Baptiste Onofré
> > > > jbonofre@apache.org
> > > > http://blog.nanthrax.net
> > > > Talend - http://www.talend.com
> > > >
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Neelesh S. Salian
> > >
> >
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Sourabh Bajaj <so...@google.com.INVALID>.
For 6. I think having them in one page on the website where we can find the
design docs more easily would be great.
7. For low-hanging-fruit, one thing I really liked from some Mozilla
projects was assigning a mentor on the ticket. Someone you can reach out to
if you have questions. I think this makes the entry barrier really low for
first time contributors who might feel intimidated asking questions
completely in public.
On Mon, Apr 24, 2017 at 10:06 AM Kenneth Knowles <kl...@google.com.invalid>
wrote:
> I like the subject Etienne has brought up, and will give it a number in
> this list :-)
>
> 6. Have more technical reference docs (not just workspace set up) for
> contributors.
>
> I think this overlaps a lot with a prior discussion about where to collect
> design proposals [1]. Design docs used to be just dropped into a public
> folder, but that got disorganized. And that thread was about work in
> progress, so JIRA was a good place for details after a dev@ thread agrees
> on a proposal. At this point, the designs are pretty solid conceptually or
> even implemented and we could start to build out deeper technical bits on
> the web site, or at least some place that people can find it. We do have
> the Testing Guide and the PTransform Style Guide and somewhere near there
> we could have deeper references. I think we need a broader vision for the
> "table of contents" here.
>
> For my docs (triggers, lateness, runner API, side inputs, state, coders) I
> haven't had time, but I do intend to both translate from GDoc to some other
> format and also rewrite versions for users where appropriate. Probably this
> will mean coming up with that table of contents.
>
> Kenn
>
> [1]
>
> https://lists.apache.org/thread.html/%3C6bc60c88-cf91-4fff-eae6-fea6ee06f662@nanthrax.net%3E
>
>
> On Mon, Apr 24, 2017 at 9:33 AM, Neelesh Salian <ne...@gmail.com>
> wrote:
>
> > Agreed. I have some old JIRAs that I am cleaning up.
> >
> > Thank you for bringing this up.
> >
> > On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> > wrote:
> >
> > > Same also for Slack, github comments, etc.
> > >
> > > From a Apache perspective, it should happen on the mailing list,
> > > eventually referencing a central wiki/faq/whatever.
> > >
> > > Regards
> > > JB
> > >
> > >
> > > On 04/24/2017 06:23 PM, Mingmin Xu wrote:
> > >
> > >> many design documents are mixed in maillist, jira comments, it would
> be
> > a
> > >> big help to put them in a centralized list. Also I would expect more
> > >> wiki/blogs to provide in-depth analysis, like the translation from
> > >> pipeline
> > >> to runner specified topology, window/trigger implementation. Without
> > these
> > >> knowledge, it's hard to touch the core concepts.
> > >>
> > >> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofré <
> jb@nanthrax.net>
> > >> wrote:
> > >>
> > >> Got it. By experience on other Apache projects, it's really hard to
> > >>> maintain ;)
> > >>>
> > >>> Regards
> > >>> JB
> > >>>
> > >>>
> > >>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
> > >>>
> > >>> Hi JB,
> > >>>>
> > >>>> I was proposing a FAQ (or another form), not something about IDE
> > setup.
> > >>>> The FAQ
> > >>>> could group in the same place Q/A like for example "what is a
> source,
> > >>>> how
> > >>>> do I
> > >>>> use it to implement an IO"
> > >>>>
> > >>>> Etienne
> > >>>>
> > >>>>
> > >>>> Le 24/04/2017 à 14:19, Jean-Baptiste Onofré a écrit :
> > >>>>
> > >>>> Hi Etienne,
> > >>>>>
> > >>>>> What about the contribution guide ? I think it's covered in the
> > >>>>> IntelliJ
> > >>>>> and
> > >>>>> Eclipse setup sections.
> > >>>>>
> > >>>>> Regards
> > >>>>> JB
> > >>>>>
> > >>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
> > >>>>>
> > >>>>> Hi all,
> > >>>>>>
> > >>>>>> I definitely agree with everything that is said in this thread.
> > >>>>>>
> > >>>>>> I might suggest another good to have:
> > >>>>>>
> > >>>>>> to ease the work of a new contributor, it would be nice to have
> some
> > >>>>>> sort of
> > >>>>>> programming guide but not oriented to pipeline writers but to
> > >>>>>> sdk/runner/io/...
> > >>>>>> writers.
> > >>>>>>
> > >>>>>> I know that new contributors have the docs available in the google
> > >>>>>> drive, the
> > >>>>>> ML, the code base, and the availability of beamers, but maybe
> having
> > >>>>>> key points
> > >>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for
> > >>>>>> example)
> > >>>>>> would be
> > >>>>>> interesting.
> > >>>>>>
> > >>>>>> Best,
> > >>>>>>
> > >>>>>> Etienne
> > >>>>>>
> > >>>>>>
> > >>>>>> Le 24/04/2017 à 09:14, Jean-Baptiste Onofré a écrit :
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>>
> > >>>>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
> > >>>>>>>
> > >>>>>>> Good idea for domain of interest/concept.
> > >>>>>>>
> > >>>>>>> Regards
> > >>>>>>> JB
> > >>>>>>>
> > >>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
> > >>>>>>>
> > >>>>>>> Might I suggest adding tags to projects based on area of
> intetest,
> > >>>>>>>> concept
> > >>>>>>>> and if it's a good "first bug".
> > >>>>>>>>
> > >>>>>>>> Sent from my iPhone
> > >>>>>>>>
> > >>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org>
> wrote:
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> 1. Have people unassign themselves from issues they're not
> > actively
> > >>>>>>>>>> working on.
> > >>>>>>>>>> 2. Have the community engage more in triage, improving tickets
> > >>>>>>>>>> descriptions and raising concerns.
> > >>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over
> 800).
> > >>>>>>>>>> Perhaps
> > >>>>>>>>>> some can be closed.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> +1 on all three of these, and will do my part shortly!
> > >>>>>>>>>
> > >>>>>>>>> Also, it is worth noting that we have improved as a project in
> > >>>>>>>>> tracking
> > >>>>>>>>> issues in the last 1-2 months. There are more resolved issues
> > than
> > >>>>>>>>> opened
> > >>>>>>>>> in this period, whereas in the past we'd have a hundred more
> > opened
> > >>>>>>>>> than
> > >>>>>>>>> resolved.
> > >>>>>>>>>
> > >>>>>>>>> I would also propose to not assign new Jira automatically: now,
> > the
> > >>>>>>>>> Jira is
> > >>>>>>>>>
> > >>>>>>>>> automatically assigned to the Jira component leader.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Imagine a user discovering an issue and filing a new JIRA
> issue.
> > >>>>>>>>> It
> > >>>>>>>>> wouldn't be assigned to anyone, significantly reducing the
> chance
> > >>>>>>>>> somebody
> > >>>>>>>>> will actually help.
> > >>>>>>>>>
> > >>>>>>>>> Of course, somebody could search for new issues periodically,
> > etc.
> > >>>>>>>>> -- but
> > >>>>>>>>> that just won't happen. The final outcome would be -- instead
> of
> > a
> > >>>>>>>>> lot of
> > >>>>>>>>> issues assigned to component leads, we'd have (much) more
> > >>>>>>>>> unassigned
> > >>>>>>>>> issues, which were *never* looked at. Assigning an issue just
> > sets
> > >>>>>>>>> a
> > >>>>>>>>> community expectation that a committer should look -- and it
> does
> > >>>>>>>>> help move
> > >>>>>>>>> things along!
> > >>>>>>>>>
> > >>>>>>>>> I think a better approach of addressing the current state would
> > be
> > >>>>>>>>> increase
> > >>>>>>>>> the number of components / component leads. With more people
> > >>>>>>>>> involved and
> > >>>>>>>>> lower per-person load, I think we'd be more effective.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>> --
> > >>> Jean-Baptiste Onofré
> > >>> jbonofre@apache.org
> > >>> http://blog.nanthrax.net
> > >>> Talend - http://www.talend.com
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > > --
> > > Jean-Baptiste Onofré
> > > jbonofre@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
> >
> >
> > --
> > Regards,
> > Neelesh S. Salian
> >
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Etienne Chauchot <ec...@gmail.com>.
You're right Kenn, discussing the "table of contents" is a good start.
WDYT about having this table of contents audience and code package
oriented? something like
1. SDK writers
1.1 Core components
1.1.1 Transforms
1.1.2 Metrics
....
1.2 IO components
...
2. Runner writers
1.1 Direct Runner
1.2 Flink Runner
1.3 Spark Runner
....
Etienne
Le 24/04/2017 � 19:06, Kenneth Knowles a �crit :
> I like the subject Etienne has brought up, and will give it a number in
> this list :-)
>
> 6. Have more technical reference docs (not just workspace set up) for
> contributors.
>
> I think this overlaps a lot with a prior discussion about where to collect
> design proposals [1]. Design docs used to be just dropped into a public
> folder, but that got disorganized. And that thread was about work in
> progress, so JIRA was a good place for details after a dev@ thread agrees
> on a proposal. At this point, the designs are pretty solid conceptually or
> even implemented and we could start to build out deeper technical bits on
> the web site, or at least some place that people can find it. We do have
> the Testing Guide and the PTransform Style Guide and somewhere near there
> we could have deeper references. I think we need a broader vision for the
> "table of contents" here.
>
> For my docs (triggers, lateness, runner API, side inputs, state, coders) I
> haven't had time, but I do intend to both translate from GDoc to some other
> format and also rewrite versions for users where appropriate. Probably this
> will mean coming up with that table of contents.
>
> Kenn
>
> [1]
> https://lists.apache.org/thread.html/%3C6bc60c88-cf91-4fff-eae6-fea6ee06f662@nanthrax.net%3E
>
>
> On Mon, Apr 24, 2017 at 9:33 AM, Neelesh Salian <ne...@gmail.com>
> wrote:
>
>> Agreed. I have some old JIRAs that I am cleaning up.
>>
>> Thank you for bringing this up.
>>
>> On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
>> wrote:
>>
>>> Same also for Slack, github comments, etc.
>>>
>>> From a Apache perspective, it should happen on the mailing list,
>>> eventually referencing a central wiki/faq/whatever.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 04/24/2017 06:23 PM, Mingmin Xu wrote:
>>>
>>>> many design documents are mixed in maillist, jira comments, it would be
>> a
>>>> big help to put them in a centralized list. Also I would expect more
>>>> wiki/blogs to provide in-depth analysis, like the translation from
>>>> pipeline
>>>> to runner specified topology, window/trigger implementation. Without
>> these
>>>> knowledge, it's hard to touch the core concepts.
>>>>
>>>> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
>>>> wrote:
>>>>
>>>> Got it. By experience on other Apache projects, it's really hard to
>>>>> maintain ;)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
>>>>>
>>>>> Hi JB,
>>>>>> I was proposing a FAQ (or another form), not something about IDE
>> setup.
>>>>>> The FAQ
>>>>>> could group in the same place Q/A like for example "what is a source,
>>>>>> how
>>>>>> do I
>>>>>> use it to implement an IO"
>>>>>>
>>>>>> Etienne
>>>>>>
>>>>>>
>>>>>> Le 24/04/2017 � 14:19, Jean-Baptiste Onofr� a �crit :
>>>>>>
>>>>>> Hi Etienne,
>>>>>>> What about the contribution guide ? I think it's covered in the
>>>>>>> IntelliJ
>>>>>>> and
>>>>>>> Eclipse setup sections.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>> I definitely agree with everything that is said in this thread.
>>>>>>>>
>>>>>>>> I might suggest another good to have:
>>>>>>>>
>>>>>>>> to ease the work of a new contributor, it would be nice to have some
>>>>>>>> sort of
>>>>>>>> programming guide but not oriented to pipeline writers but to
>>>>>>>> sdk/runner/io/...
>>>>>>>> writers.
>>>>>>>>
>>>>>>>> I know that new contributors have the docs available in the google
>>>>>>>> drive, the
>>>>>>>> ML, the code base, and the availability of beamers, but maybe having
>>>>>>>> key points
>>>>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for
>>>>>>>> example)
>>>>>>>> would be
>>>>>>>> interesting.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Etienne
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 24/04/2017 � 09:14, Jean-Baptiste Onofr� a �crit :
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>>>>>>>>
>>>>>>>>> Good idea for domain of interest/concept.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>>>>>>>
>>>>>>>>> Might I suggest adding tags to projects based on area of intetest,
>>>>>>>>>> concept
>>>>>>>>>> and if it's a good "first bug".
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1. Have people unassign themselves from issues they're not
>> actively
>>>>>>>>>>>> working on.
>>>>>>>>>>>> 2. Have the community engage more in triage, improving tickets
>>>>>>>>>>>> descriptions and raising concerns.
>>>>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over 800).
>>>>>>>>>>>> Perhaps
>>>>>>>>>>>> some can be closed.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> +1 on all three of these, and will do my part shortly!
>>>>>>>>>>> Also, it is worth noting that we have improved as a project in
>>>>>>>>>>> tracking
>>>>>>>>>>> issues in the last 1-2 months. There are more resolved issues
>> than
>>>>>>>>>>> opened
>>>>>>>>>>> in this period, whereas in the past we'd have a hundred more
>> opened
>>>>>>>>>>> than
>>>>>>>>>>> resolved.
>>>>>>>>>>>
>>>>>>>>>>> I would also propose to not assign new Jira automatically: now,
>> the
>>>>>>>>>>> Jira is
>>>>>>>>>>>
>>>>>>>>>>> automatically assigned to the Jira component leader.
>>>>>>>>>>>>
>>>>>>>>>>>> Imagine a user discovering an issue and filing a new JIRA issue.
>>>>>>>>>>> It
>>>>>>>>>>> wouldn't be assigned to anyone, significantly reducing the chance
>>>>>>>>>>> somebody
>>>>>>>>>>> will actually help.
>>>>>>>>>>>
>>>>>>>>>>> Of course, somebody could search for new issues periodically,
>> etc.
>>>>>>>>>>> -- but
>>>>>>>>>>> that just won't happen. The final outcome would be -- instead of
>> a
>>>>>>>>>>> lot of
>>>>>>>>>>> issues assigned to component leads, we'd have (much) more
>>>>>>>>>>> unassigned
>>>>>>>>>>> issues, which were *never* looked at. Assigning an issue just
>> sets
>>>>>>>>>>> a
>>>>>>>>>>> community expectation that a committer should look -- and it does
>>>>>>>>>>> help move
>>>>>>>>>>> things along!
>>>>>>>>>>>
>>>>>>>>>>> I think a better approach of addressing the current state would
>> be
>>>>>>>>>>> increase
>>>>>>>>>>> the number of components / component leads. With more people
>>>>>>>>>>> involved and
>>>>>>>>>>> lower per-person load, I think we'd be more effective.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> --
>>>>> Jean-Baptiste Onofr�
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofr�
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>> --
>> Regards,
>> Neelesh S. Salian
>>
Re: [DISCUSSION] Encouraging more contributions
Posted by Kenneth Knowles <kl...@google.com.INVALID>.
I like the subject Etienne has brought up, and will give it a number in
this list :-)
6. Have more technical reference docs (not just workspace set up) for
contributors.
I think this overlaps a lot with a prior discussion about where to collect
design proposals [1]. Design docs used to be just dropped into a public
folder, but that got disorganized. And that thread was about work in
progress, so JIRA was a good place for details after a dev@ thread agrees
on a proposal. At this point, the designs are pretty solid conceptually or
even implemented and we could start to build out deeper technical bits on
the web site, or at least some place that people can find it. We do have
the Testing Guide and the PTransform Style Guide and somewhere near there
we could have deeper references. I think we need a broader vision for the
"table of contents" here.
For my docs (triggers, lateness, runner API, side inputs, state, coders) I
haven't had time, but I do intend to both translate from GDoc to some other
format and also rewrite versions for users where appropriate. Probably this
will mean coming up with that table of contents.
Kenn
[1]
https://lists.apache.org/thread.html/%3C6bc60c88-cf91-4fff-eae6-fea6ee06f662@nanthrax.net%3E
On Mon, Apr 24, 2017 at 9:33 AM, Neelesh Salian <ne...@gmail.com>
wrote:
> Agreed. I have some old JIRAs that I am cleaning up.
>
> Thank you for bringing this up.
>
> On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > Same also for Slack, github comments, etc.
> >
> > From a Apache perspective, it should happen on the mailing list,
> > eventually referencing a central wiki/faq/whatever.
> >
> > Regards
> > JB
> >
> >
> > On 04/24/2017 06:23 PM, Mingmin Xu wrote:
> >
> >> many design documents are mixed in maillist, jira comments, it would be
> a
> >> big help to put them in a centralized list. Also I would expect more
> >> wiki/blogs to provide in-depth analysis, like the translation from
> >> pipeline
> >> to runner specified topology, window/trigger implementation. Without
> these
> >> knowledge, it's hard to touch the core concepts.
> >>
> >> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> >> wrote:
> >>
> >> Got it. By experience on other Apache projects, it's really hard to
> >>> maintain ;)
> >>>
> >>> Regards
> >>> JB
> >>>
> >>>
> >>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
> >>>
> >>> Hi JB,
> >>>>
> >>>> I was proposing a FAQ (or another form), not something about IDE
> setup.
> >>>> The FAQ
> >>>> could group in the same place Q/A like for example "what is a source,
> >>>> how
> >>>> do I
> >>>> use it to implement an IO"
> >>>>
> >>>> Etienne
> >>>>
> >>>>
> >>>> Le 24/04/2017 à 14:19, Jean-Baptiste Onofré a écrit :
> >>>>
> >>>> Hi Etienne,
> >>>>>
> >>>>> What about the contribution guide ? I think it's covered in the
> >>>>> IntelliJ
> >>>>> and
> >>>>> Eclipse setup sections.
> >>>>>
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>>
> >>>>>> I definitely agree with everything that is said in this thread.
> >>>>>>
> >>>>>> I might suggest another good to have:
> >>>>>>
> >>>>>> to ease the work of a new contributor, it would be nice to have some
> >>>>>> sort of
> >>>>>> programming guide but not oriented to pipeline writers but to
> >>>>>> sdk/runner/io/...
> >>>>>> writers.
> >>>>>>
> >>>>>> I know that new contributors have the docs available in the google
> >>>>>> drive, the
> >>>>>> ML, the code base, and the availability of beamers, but maybe having
> >>>>>> key points
> >>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for
> >>>>>> example)
> >>>>>> would be
> >>>>>> interesting.
> >>>>>>
> >>>>>> Best,
> >>>>>>
> >>>>>> Etienne
> >>>>>>
> >>>>>>
> >>>>>> Le 24/04/2017 à 09:14, Jean-Baptiste Onofré a écrit :
> >>>>>>
> >>>>>> Hi,
> >>>>>>>
> >>>>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
> >>>>>>>
> >>>>>>> Good idea for domain of interest/concept.
> >>>>>>>
> >>>>>>> Regards
> >>>>>>> JB
> >>>>>>>
> >>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
> >>>>>>>
> >>>>>>> Might I suggest adding tags to projects based on area of intetest,
> >>>>>>>> concept
> >>>>>>>> and if it's a good "first bug".
> >>>>>>>>
> >>>>>>>> Sent from my iPhone
> >>>>>>>>
> >>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 1. Have people unassign themselves from issues they're not
> actively
> >>>>>>>>>> working on.
> >>>>>>>>>> 2. Have the community engage more in triage, improving tickets
> >>>>>>>>>> descriptions and raising concerns.
> >>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over 800).
> >>>>>>>>>> Perhaps
> >>>>>>>>>> some can be closed.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> +1 on all three of these, and will do my part shortly!
> >>>>>>>>>
> >>>>>>>>> Also, it is worth noting that we have improved as a project in
> >>>>>>>>> tracking
> >>>>>>>>> issues in the last 1-2 months. There are more resolved issues
> than
> >>>>>>>>> opened
> >>>>>>>>> in this period, whereas in the past we'd have a hundred more
> opened
> >>>>>>>>> than
> >>>>>>>>> resolved.
> >>>>>>>>>
> >>>>>>>>> I would also propose to not assign new Jira automatically: now,
> the
> >>>>>>>>> Jira is
> >>>>>>>>>
> >>>>>>>>> automatically assigned to the Jira component leader.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Imagine a user discovering an issue and filing a new JIRA issue.
> >>>>>>>>> It
> >>>>>>>>> wouldn't be assigned to anyone, significantly reducing the chance
> >>>>>>>>> somebody
> >>>>>>>>> will actually help.
> >>>>>>>>>
> >>>>>>>>> Of course, somebody could search for new issues periodically,
> etc.
> >>>>>>>>> -- but
> >>>>>>>>> that just won't happen. The final outcome would be -- instead of
> a
> >>>>>>>>> lot of
> >>>>>>>>> issues assigned to component leads, we'd have (much) more
> >>>>>>>>> unassigned
> >>>>>>>>> issues, which were *never* looked at. Assigning an issue just
> sets
> >>>>>>>>> a
> >>>>>>>>> community expectation that a committer should look -- and it does
> >>>>>>>>> help move
> >>>>>>>>> things along!
> >>>>>>>>>
> >>>>>>>>> I think a better approach of addressing the current state would
> be
> >>>>>>>>> increase
> >>>>>>>>> the number of components / component leads. With more people
> >>>>>>>>> involved and
> >>>>>>>>> lower per-person load, I think we'd be more effective.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>> --
> >>> Jean-Baptiste Onofré
> >>> jbonofre@apache.org
> >>> http://blog.nanthrax.net
> >>> Talend - http://www.talend.com
> >>>
> >>>
> >>
> >>
> >>
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
> Regards,
> Neelesh S. Salian
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Neelesh Salian <ne...@gmail.com>.
Agreed. I have some old JIRAs that I am cleaning up.
Thank you for bringing this up.
On Mon, Apr 24, 2017 at 9:29 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Same also for Slack, github comments, etc.
>
> From a Apache perspective, it should happen on the mailing list,
> eventually referencing a central wiki/faq/whatever.
>
> Regards
> JB
>
>
> On 04/24/2017 06:23 PM, Mingmin Xu wrote:
>
>> many design documents are mixed in maillist, jira comments, it would be a
>> big help to put them in a centralized list. Also I would expect more
>> wiki/blogs to provide in-depth analysis, like the translation from
>> pipeline
>> to runner specified topology, window/trigger implementation. Without these
>> knowledge, it's hard to touch the core concepts.
>>
>> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>> Got it. By experience on other Apache projects, it's really hard to
>>> maintain ;)
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
>>>
>>> Hi JB,
>>>>
>>>> I was proposing a FAQ (or another form), not something about IDE setup.
>>>> The FAQ
>>>> could group in the same place Q/A like for example "what is a source,
>>>> how
>>>> do I
>>>> use it to implement an IO"
>>>>
>>>> Etienne
>>>>
>>>>
>>>> Le 24/04/2017 à 14:19, Jean-Baptiste Onofré a écrit :
>>>>
>>>> Hi Etienne,
>>>>>
>>>>> What about the contribution guide ? I think it's covered in the
>>>>> IntelliJ
>>>>> and
>>>>> Eclipse setup sections.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>>>>>
>>>>> Hi all,
>>>>>>
>>>>>> I definitely agree with everything that is said in this thread.
>>>>>>
>>>>>> I might suggest another good to have:
>>>>>>
>>>>>> to ease the work of a new contributor, it would be nice to have some
>>>>>> sort of
>>>>>> programming guide but not oriented to pipeline writers but to
>>>>>> sdk/runner/io/...
>>>>>> writers.
>>>>>>
>>>>>> I know that new contributors have the docs available in the google
>>>>>> drive, the
>>>>>> ML, the code base, and the availability of beamers, but maybe having
>>>>>> key points
>>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for
>>>>>> example)
>>>>>> would be
>>>>>> interesting.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Etienne
>>>>>>
>>>>>>
>>>>>> Le 24/04/2017 à 09:14, Jean-Baptiste Onofré a écrit :
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>>>>>>
>>>>>>> Good idea for domain of interest/concept.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>>>>>
>>>>>>> Might I suggest adding tags to projects based on area of intetest,
>>>>>>>> concept
>>>>>>>> and if it's a good "first bug".
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 1. Have people unassign themselves from issues they're not actively
>>>>>>>>>> working on.
>>>>>>>>>> 2. Have the community engage more in triage, improving tickets
>>>>>>>>>> descriptions and raising concerns.
>>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over 800).
>>>>>>>>>> Perhaps
>>>>>>>>>> some can be closed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +1 on all three of these, and will do my part shortly!
>>>>>>>>>
>>>>>>>>> Also, it is worth noting that we have improved as a project in
>>>>>>>>> tracking
>>>>>>>>> issues in the last 1-2 months. There are more resolved issues than
>>>>>>>>> opened
>>>>>>>>> in this period, whereas in the past we'd have a hundred more opened
>>>>>>>>> than
>>>>>>>>> resolved.
>>>>>>>>>
>>>>>>>>> I would also propose to not assign new Jira automatically: now, the
>>>>>>>>> Jira is
>>>>>>>>>
>>>>>>>>> automatically assigned to the Jira component leader.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Imagine a user discovering an issue and filing a new JIRA issue.
>>>>>>>>> It
>>>>>>>>> wouldn't be assigned to anyone, significantly reducing the chance
>>>>>>>>> somebody
>>>>>>>>> will actually help.
>>>>>>>>>
>>>>>>>>> Of course, somebody could search for new issues periodically, etc.
>>>>>>>>> -- but
>>>>>>>>> that just won't happen. The final outcome would be -- instead of a
>>>>>>>>> lot of
>>>>>>>>> issues assigned to component leads, we'd have (much) more
>>>>>>>>> unassigned
>>>>>>>>> issues, which were *never* looked at. Assigning an issue just sets
>>>>>>>>> a
>>>>>>>>> community expectation that a committer should look -- and it does
>>>>>>>>> help move
>>>>>>>>> things along!
>>>>>>>>>
>>>>>>>>> I think a better approach of addressing the current state would be
>>>>>>>>> increase
>>>>>>>>> the number of components / component leads. With more people
>>>>>>>>> involved and
>>>>>>>>> lower per-person load, I think we'd be more effective.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Regards,
Neelesh S. Salian
Re: [DISCUSSION] Encouraging more contributions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Same also for Slack, github comments, etc.
From a Apache perspective, it should happen on the mailing list, eventually
referencing a central wiki/faq/whatever.
Regards
JB
On 04/24/2017 06:23 PM, Mingmin Xu wrote:
> many design documents are mixed in maillist, jira comments, it would be a
> big help to put them in a centralized list. Also I would expect more
> wiki/blogs to provide in-depth analysis, like the translation from pipeline
> to runner specified topology, window/trigger implementation. Without these
> knowledge, it's hard to touch the core concepts.
>
> On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net>
> wrote:
>
>> Got it. By experience on other Apache projects, it's really hard to
>> maintain ;)
>>
>> Regards
>> JB
>>
>>
>> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
>>
>>> Hi JB,
>>>
>>> I was proposing a FAQ (or another form), not something about IDE setup.
>>> The FAQ
>>> could group in the same place Q/A like for example "what is a source, how
>>> do I
>>> use it to implement an IO"
>>>
>>> Etienne
>>>
>>>
>>> Le 24/04/2017 � 14:19, Jean-Baptiste Onofr� a �crit :
>>>
>>>> Hi Etienne,
>>>>
>>>> What about the contribution guide ? I think it's covered in the IntelliJ
>>>> and
>>>> Eclipse setup sections.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I definitely agree with everything that is said in this thread.
>>>>>
>>>>> I might suggest another good to have:
>>>>>
>>>>> to ease the work of a new contributor, it would be nice to have some
>>>>> sort of
>>>>> programming guide but not oriented to pipeline writers but to
>>>>> sdk/runner/io/...
>>>>> writers.
>>>>>
>>>>> I know that new contributors have the docs available in the google
>>>>> drive, the
>>>>> ML, the code base, and the availability of beamers, but maybe having
>>>>> key points
>>>>> in a common place (like FAQ for sdk/runner/io/... writers, for example)
>>>>> would be
>>>>> interesting.
>>>>>
>>>>> Best,
>>>>>
>>>>> Etienne
>>>>>
>>>>>
>>>>> Le 24/04/2017 � 09:14, Jean-Baptiste Onofr� a �crit :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>>>>>
>>>>>> Good idea for domain of interest/concept.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>>>>
>>>>>>> Might I suggest adding tags to projects based on area of intetest,
>>>>>>> concept
>>>>>>> and if it's a good "first bug".
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>> 1. Have people unassign themselves from issues they're not actively
>>>>>>>>> working on.
>>>>>>>>> 2. Have the community engage more in triage, improving tickets
>>>>>>>>> descriptions and raising concerns.
>>>>>>>>> 3. Clean house - apply (2) to currently open issues (over 800).
>>>>>>>>> Perhaps
>>>>>>>>> some can be closed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> +1 on all three of these, and will do my part shortly!
>>>>>>>>
>>>>>>>> Also, it is worth noting that we have improved as a project in
>>>>>>>> tracking
>>>>>>>> issues in the last 1-2 months. There are more resolved issues than
>>>>>>>> opened
>>>>>>>> in this period, whereas in the past we'd have a hundred more opened
>>>>>>>> than
>>>>>>>> resolved.
>>>>>>>>
>>>>>>>> I would also propose to not assign new Jira automatically: now, the
>>>>>>>> Jira is
>>>>>>>>
>>>>>>>>> automatically assigned to the Jira component leader.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Imagine a user discovering an issue and filing a new JIRA issue. It
>>>>>>>> wouldn't be assigned to anyone, significantly reducing the chance
>>>>>>>> somebody
>>>>>>>> will actually help.
>>>>>>>>
>>>>>>>> Of course, somebody could search for new issues periodically, etc.
>>>>>>>> -- but
>>>>>>>> that just won't happen. The final outcome would be -- instead of a
>>>>>>>> lot of
>>>>>>>> issues assigned to component leads, we'd have (much) more unassigned
>>>>>>>> issues, which were *never* looked at. Assigning an issue just sets a
>>>>>>>> community expectation that a committer should look -- and it does
>>>>>>>> help move
>>>>>>>> things along!
>>>>>>>>
>>>>>>>> I think a better approach of addressing the current state would be
>>>>>>>> increase
>>>>>>>> the number of components / component leads. With more people
>>>>>>>> involved and
>>>>>>>> lower per-person load, I think we'd be more effective.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSSION] Encouraging more contributions
Posted by Mingmin Xu <mi...@gmail.com>.
many design documents are mixed in maillist, jira comments, it would be a
big help to put them in a centralized list. Also I would expect more
wiki/blogs to provide in-depth analysis, like the translation from pipeline
to runner specified topology, window/trigger implementation. Without these
knowledge, it's hard to touch the core concepts.
On Mon, Apr 24, 2017 at 6:03 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Got it. By experience on other Apache projects, it's really hard to
> maintain ;)
>
> Regards
> JB
>
>
> On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
>
>> Hi JB,
>>
>> I was proposing a FAQ (or another form), not something about IDE setup.
>> The FAQ
>> could group in the same place Q/A like for example "what is a source, how
>> do I
>> use it to implement an IO"
>>
>> Etienne
>>
>>
>> Le 24/04/2017 à 14:19, Jean-Baptiste Onofré a écrit :
>>
>>> Hi Etienne,
>>>
>>> What about the contribution guide ? I think it's covered in the IntelliJ
>>> and
>>> Eclipse setup sections.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>>>
>>>> Hi all,
>>>>
>>>> I definitely agree with everything that is said in this thread.
>>>>
>>>> I might suggest another good to have:
>>>>
>>>> to ease the work of a new contributor, it would be nice to have some
>>>> sort of
>>>> programming guide but not oriented to pipeline writers but to
>>>> sdk/runner/io/...
>>>> writers.
>>>>
>>>> I know that new contributors have the docs available in the google
>>>> drive, the
>>>> ML, the code base, and the availability of beamers, but maybe having
>>>> key points
>>>> in a common place (like FAQ for sdk/runner/io/... writers, for example)
>>>> would be
>>>> interesting.
>>>>
>>>> Best,
>>>>
>>>> Etienne
>>>>
>>>>
>>>> Le 24/04/2017 à 09:14, Jean-Baptiste Onofré a écrit :
>>>>
>>>>> Hi,
>>>>>
>>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>>>>
>>>>> Good idea for domain of interest/concept.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>>>
>>>>>> Might I suggest adding tags to projects based on area of intetest,
>>>>>> concept
>>>>>> and if it's a good "first bug".
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>>>>
>>>>>>
>>>>>>>> 1. Have people unassign themselves from issues they're not actively
>>>>>>>> working on.
>>>>>>>> 2. Have the community engage more in triage, improving tickets
>>>>>>>> descriptions and raising concerns.
>>>>>>>> 3. Clean house - apply (2) to currently open issues (over 800).
>>>>>>>> Perhaps
>>>>>>>> some can be closed.
>>>>>>>>
>>>>>>>>
>>>>>>> +1 on all three of these, and will do my part shortly!
>>>>>>>
>>>>>>> Also, it is worth noting that we have improved as a project in
>>>>>>> tracking
>>>>>>> issues in the last 1-2 months. There are more resolved issues than
>>>>>>> opened
>>>>>>> in this period, whereas in the past we'd have a hundred more opened
>>>>>>> than
>>>>>>> resolved.
>>>>>>>
>>>>>>> I would also propose to not assign new Jira automatically: now, the
>>>>>>> Jira is
>>>>>>>
>>>>>>>> automatically assigned to the Jira component leader.
>>>>>>>>
>>>>>>>>
>>>>>>> Imagine a user discovering an issue and filing a new JIRA issue. It
>>>>>>> wouldn't be assigned to anyone, significantly reducing the chance
>>>>>>> somebody
>>>>>>> will actually help.
>>>>>>>
>>>>>>> Of course, somebody could search for new issues periodically, etc.
>>>>>>> -- but
>>>>>>> that just won't happen. The final outcome would be -- instead of a
>>>>>>> lot of
>>>>>>> issues assigned to component leads, we'd have (much) more unassigned
>>>>>>> issues, which were *never* looked at. Assigning an issue just sets a
>>>>>>> community expectation that a committer should look -- and it does
>>>>>>> help move
>>>>>>> things along!
>>>>>>>
>>>>>>> I think a better approach of addressing the current state would be
>>>>>>> increase
>>>>>>> the number of components / component leads. With more people
>>>>>>> involved and
>>>>>>> lower per-person load, I think we'd be more effective.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
----
Mingmin
Re: [DISCUSSION] Encouraging more contributions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Got it. By experience on other Apache projects, it's really hard to maintain ;)
Regards
JB
On 04/24/2017 02:56 PM, Etienne Chauchot wrote:
> Hi JB,
>
> I was proposing a FAQ (or another form), not something about IDE setup. The FAQ
> could group in the same place Q/A like for example "what is a source, how do I
> use it to implement an IO"
>
> Etienne
>
>
> Le 24/04/2017 14:19, Jean-Baptiste Onofr a crit :
>> Hi Etienne,
>>
>> What about the contribution guide ? I think it's covered in the IntelliJ and
>> Eclipse setup sections.
>>
>> Regards
>> JB
>>
>> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>>> Hi all,
>>>
>>> I definitely agree with everything that is said in this thread.
>>>
>>> I might suggest another good to have:
>>>
>>> to ease the work of a new contributor, it would be nice to have some sort of
>>> programming guide but not oriented to pipeline writers but to sdk/runner/io/...
>>> writers.
>>>
>>> I know that new contributors have the docs available in the google drive, the
>>> ML, the code base, and the availability of beamers, but maybe having key points
>>> in a common place (like FAQ for sdk/runner/io/... writers, for example) would be
>>> interesting.
>>>
>>> Best,
>>>
>>> Etienne
>>>
>>>
>>> Le 24/04/2017 09:14, Jean-Baptiste Onofr a crit :
>>>> Hi,
>>>>
>>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>>>
>>>> Good idea for domain of interest/concept.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>>> Might I suggest adding tags to projects based on area of intetest, concept
>>>>> and if it's a good "first bug".
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>>>
>>>>>>>
>>>>>>> 1. Have people unassign themselves from issues they're not actively
>>>>>>> working on.
>>>>>>> 2. Have the community engage more in triage, improving tickets
>>>>>>> descriptions and raising concerns.
>>>>>>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>>>>>>> some can be closed.
>>>>>>>
>>>>>>
>>>>>> +1 on all three of these, and will do my part shortly!
>>>>>>
>>>>>> Also, it is worth noting that we have improved as a project in tracking
>>>>>> issues in the last 1-2 months. There are more resolved issues than opened
>>>>>> in this period, whereas in the past we'd have a hundred more opened than
>>>>>> resolved.
>>>>>>
>>>>>> I would also propose to not assign new Jira automatically: now, the Jira is
>>>>>>> automatically assigned to the Jira component leader.
>>>>>>>
>>>>>>
>>>>>> Imagine a user discovering an issue and filing a new JIRA issue. It
>>>>>> wouldn't be assigned to anyone, significantly reducing the chance somebody
>>>>>> will actually help.
>>>>>>
>>>>>> Of course, somebody could search for new issues periodically, etc. -- but
>>>>>> that just won't happen. The final outcome would be -- instead of a lot of
>>>>>> issues assigned to component leads, we'd have (much) more unassigned
>>>>>> issues, which were *never* looked at. Assigning an issue just sets a
>>>>>> community expectation that a committer should look -- and it does help move
>>>>>> things along!
>>>>>>
>>>>>> I think a better approach of addressing the current state would be increase
>>>>>> the number of components / component leads. With more people involved and
>>>>>> lower per-person load, I think we'd be more effective.
>>>>
>>>
>>
>
--
Jean-Baptiste Onofr
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSSION] Encouraging more contributions
Posted by Etienne Chauchot <ec...@gmail.com>.
Hi JB,
I was proposing a FAQ (or another form), not something about IDE setup.
The FAQ could group in the same place Q/A like for example "what is a
source, how do I use it to implement an IO"
Etienne
Le 24/04/2017 14:19, Jean-Baptiste Onofr a crit :
> Hi Etienne,
>
> What about the contribution guide ? I think it's covered in the
> IntelliJ and Eclipse setup sections.
>
> Regards
> JB
>
> On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
>> Hi all,
>>
>> I definitely agree with everything that is said in this thread.
>>
>> I might suggest another good to have:
>>
>> to ease the work of a new contributor, it would be nice to have some
>> sort of
>> programming guide but not oriented to pipeline writers but to
>> sdk/runner/io/...
>> writers.
>>
>> I know that new contributors have the docs available in the google
>> drive, the
>> ML, the code base, and the availability of beamers, but maybe having
>> key points
>> in a common place (like FAQ for sdk/runner/io/... writers, for
>> example) would be
>> interesting.
>>
>> Best,
>>
>> Etienne
>>
>>
>> Le 24/04/2017 09:14, Jean-Baptiste Onofr a crit :
>>> Hi,
>>>
>>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>>
>>> Good idea for domain of interest/concept.
>>>
>>> Regards
>>> JB
>>>
>>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>>> Might I suggest adding tags to projects based on area of intetest,
>>>> concept
>>>> and if it's a good "first bug".
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>>
>>>>>>
>>>>>> 1. Have people unassign themselves from issues they're not actively
>>>>>> working on.
>>>>>> 2. Have the community engage more in triage, improving tickets
>>>>>> descriptions and raising concerns.
>>>>>> 3. Clean house - apply (2) to currently open issues (over 800).
>>>>>> Perhaps
>>>>>> some can be closed.
>>>>>>
>>>>>
>>>>> +1 on all three of these, and will do my part shortly!
>>>>>
>>>>> Also, it is worth noting that we have improved as a project in
>>>>> tracking
>>>>> issues in the last 1-2 months. There are more resolved issues than
>>>>> opened
>>>>> in this period, whereas in the past we'd have a hundred more
>>>>> opened than
>>>>> resolved.
>>>>>
>>>>> I would also propose to not assign new Jira automatically: now,
>>>>> the Jira is
>>>>>> automatically assigned to the Jira component leader.
>>>>>>
>>>>>
>>>>> Imagine a user discovering an issue and filing a new JIRA issue. It
>>>>> wouldn't be assigned to anyone, significantly reducing the chance
>>>>> somebody
>>>>> will actually help.
>>>>>
>>>>> Of course, somebody could search for new issues periodically, etc.
>>>>> -- but
>>>>> that just won't happen. The final outcome would be -- instead of a
>>>>> lot of
>>>>> issues assigned to component leads, we'd have (much) more unassigned
>>>>> issues, which were *never* looked at. Assigning an issue just sets a
>>>>> community expectation that a committer should look -- and it does
>>>>> help move
>>>>> things along!
>>>>>
>>>>> I think a better approach of addressing the current state would be
>>>>> increase
>>>>> the number of components / component leads. With more people
>>>>> involved and
>>>>> lower per-person load, I think we'd be more effective.
>>>
>>
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Etienne,
What about the contribution guide ? I think it's covered in the IntelliJ and
Eclipse setup sections.
Regards
JB
On 04/24/2017 02:12 PM, Etienne Chauchot wrote:
> Hi all,
>
> I definitely agree with everything that is said in this thread.
>
> I might suggest another good to have:
>
> to ease the work of a new contributor, it would be nice to have some sort of
> programming guide but not oriented to pipeline writers but to sdk/runner/io/...
> writers.
>
> I know that new contributors have the docs available in the google drive, the
> ML, the code base, and the availability of beamers, but maybe having key points
> in a common place (like FAQ for sdk/runner/io/... writers, for example) would be
> interesting.
>
> Best,
>
> Etienne
>
>
> Le 24/04/2017 09:14, Jean-Baptiste Onofr a crit :
>> Hi,
>>
>> I think we already tag the newbie jira ("low hanging fruit" ;)).
>>
>> Good idea for domain of interest/concept.
>>
>> Regards
>> JB
>>
>> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>>> Might I suggest adding tags to projects based on area of intetest, concept
>>> and if it's a good "first bug".
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>>
>>>>>
>>>>> 1. Have people unassign themselves from issues they're not actively
>>>>> working on.
>>>>> 2. Have the community engage more in triage, improving tickets
>>>>> descriptions and raising concerns.
>>>>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>>>>> some can be closed.
>>>>>
>>>>
>>>> +1 on all three of these, and will do my part shortly!
>>>>
>>>> Also, it is worth noting that we have improved as a project in tracking
>>>> issues in the last 1-2 months. There are more resolved issues than opened
>>>> in this period, whereas in the past we'd have a hundred more opened than
>>>> resolved.
>>>>
>>>> I would also propose to not assign new Jira automatically: now, the Jira is
>>>>> automatically assigned to the Jira component leader.
>>>>>
>>>>
>>>> Imagine a user discovering an issue and filing a new JIRA issue. It
>>>> wouldn't be assigned to anyone, significantly reducing the chance somebody
>>>> will actually help.
>>>>
>>>> Of course, somebody could search for new issues periodically, etc. -- but
>>>> that just won't happen. The final outcome would be -- instead of a lot of
>>>> issues assigned to component leads, we'd have (much) more unassigned
>>>> issues, which were *never* looked at. Assigning an issue just sets a
>>>> community expectation that a committer should look -- and it does help move
>>>> things along!
>>>>
>>>> I think a better approach of addressing the current state would be increase
>>>> the number of components / component leads. With more people involved and
>>>> lower per-person load, I think we'd be more effective.
>>
>
--
Jean-Baptiste Onofr
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSSION] Encouraging more contributions
Posted by Etienne Chauchot <ec...@gmail.com>.
Hi all,
I definitely agree with everything that is said in this thread.
I might suggest another good to have:
to ease the work of a new contributor, it would be nice to have some
sort of programming guide but not oriented to pipeline writers but to
sdk/runner/io/... writers.
I know that new contributors have the docs available in the google
drive, the ML, the code base, and the availability of beamers, but maybe
having key points in a common place (like FAQ for sdk/runner/io/...
writers, for example) would be interesting.
Best,
Etienne
Le 24/04/2017 09:14, Jean-Baptiste Onofr a crit :
> Hi,
>
> I think we already tag the newbie jira ("low hanging fruit" ;)).
>
> Good idea for domain of interest/concept.
>
> Regards
> JB
>
> On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
>> Might I suggest adding tags to projects based on area of intetest,
>> concept and if it's a good "first bug".
>>
>> Sent from my iPhone
>>
>> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>
>>>>
>>>> 1. Have people unassign themselves from issues they're not actively
>>>> working on.
>>>> 2. Have the community engage more in triage, improving tickets
>>>> descriptions and raising concerns.
>>>> 3. Clean house - apply (2) to currently open issues (over 800).
>>>> Perhaps
>>>> some can be closed.
>>>>
>>>
>>> +1 on all three of these, and will do my part shortly!
>>>
>>> Also, it is worth noting that we have improved as a project in tracking
>>> issues in the last 1-2 months. There are more resolved issues than
>>> opened
>>> in this period, whereas in the past we'd have a hundred more opened
>>> than
>>> resolved.
>>>
>>> I would also propose to not assign new Jira automatically: now, the
>>> Jira is
>>>> automatically assigned to the Jira component leader.
>>>>
>>>
>>> Imagine a user discovering an issue and filing a new JIRA issue. It
>>> wouldn't be assigned to anyone, significantly reducing the chance
>>> somebody
>>> will actually help.
>>>
>>> Of course, somebody could search for new issues periodically, etc.
>>> -- but
>>> that just won't happen. The final outcome would be -- instead of a
>>> lot of
>>> issues assigned to component leads, we'd have (much) more unassigned
>>> issues, which were *never* looked at. Assigning an issue just sets a
>>> community expectation that a committer should look -- and it does
>>> help move
>>> things along!
>>>
>>> I think a better approach of addressing the current state would be
>>> increase
>>> the number of components / component leads. With more people
>>> involved and
>>> lower per-person load, I think we'd be more effective.
>
Re: [DISCUSSION] Encouraging more contributions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I think we already tag the newbie jira ("low hanging fruit" ;)).
Good idea for domain of interest/concept.
Regards
JB
On 04/24/2017 09:01 AM, Ankur Chauhan wrote:
> Might I suggest adding tags to projects based on area of intetest, concept and if it's a good "first bug".
>
> Sent from my iPhone
>
> On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>
>>>
>>> 1. Have people unassign themselves from issues they're not actively
>>> working on.
>>> 2. Have the community engage more in triage, improving tickets
>>> descriptions and raising concerns.
>>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>>> some can be closed.
>>>
>>
>> +1 on all three of these, and will do my part shortly!
>>
>> Also, it is worth noting that we have improved as a project in tracking
>> issues in the last 1-2 months. There are more resolved issues than opened
>> in this period, whereas in the past we'd have a hundred more opened than
>> resolved.
>>
>> I would also propose to not assign new Jira automatically: now, the Jira is
>>> automatically assigned to the Jira component leader.
>>>
>>
>> Imagine a user discovering an issue and filing a new JIRA issue. It
>> wouldn't be assigned to anyone, significantly reducing the chance somebody
>> will actually help.
>>
>> Of course, somebody could search for new issues periodically, etc. -- but
>> that just won't happen. The final outcome would be -- instead of a lot of
>> issues assigned to component leads, we'd have (much) more unassigned
>> issues, which were *never* looked at. Assigning an issue just sets a
>> community expectation that a committer should look -- and it does help move
>> things along!
>>
>> I think a better approach of addressing the current state would be increase
>> the number of components / component leads. With more people involved and
>> lower per-person load, I think we'd be more effective.
--
Jean-Baptiste Onofr
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSSION] Encouraging more contributions
Posted by Ankur Chauhan <an...@malloc64.com>.
Might I suggest adding tags to projects based on area of intetest, concept and if it's a good "first bug".
Sent from my iPhone
On Apr 23, 2017, at 23:03, Davor Bonaci <da...@apache.org> wrote:
>>
>> 1. Have people unassign themselves from issues they're not actively
>> working on.
>> 2. Have the community engage more in triage, improving tickets
>> descriptions and raising concerns.
>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>> some can be closed.
>>
>
> +1 on all three of these, and will do my part shortly!
>
> Also, it is worth noting that we have improved as a project in tracking
> issues in the last 1-2 months. There are more resolved issues than opened
> in this period, whereas in the past we'd have a hundred more opened than
> resolved.
>
> I would also propose to not assign new Jira automatically: now, the Jira is
>> automatically assigned to the Jira component leader.
>>
>
> Imagine a user discovering an issue and filing a new JIRA issue. It
> wouldn't be assigned to anyone, significantly reducing the chance somebody
> will actually help.
>
> Of course, somebody could search for new issues periodically, etc. -- but
> that just won't happen. The final outcome would be -- instead of a lot of
> issues assigned to component leads, we'd have (much) more unassigned
> issues, which were *never* looked at. Assigning an issue just sets a
> community expectation that a committer should look -- and it does help move
> things along!
>
> I think a better approach of addressing the current state would be increase
> the number of components / component leads. With more people involved and
> lower per-person load, I think we'd be more effective.
Re: [DISCUSSION] Encouraging more contributions
Posted by Davor Bonaci <da...@apache.org>.
>
> 1. Have people unassign themselves from issues they're not actively
> working on.
> 2. Have the community engage more in triage, improving tickets
> descriptions and raising concerns.
> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
> some can be closed.
>
+1 on all three of these, and will do my part shortly!
Also, it is worth noting that we have improved as a project in tracking
issues in the last 1-2 months. There are more resolved issues than opened
in this period, whereas in the past we'd have a hundred more opened than
resolved.
I would also propose to not assign new Jira automatically: now, the Jira is
> automatically assigned to the Jira component leader.
>
Imagine a user discovering an issue and filing a new JIRA issue. It
wouldn't be assigned to anyone, significantly reducing the chance somebody
will actually help.
Of course, somebody could search for new issues periodically, etc. -- but
that just won't happen. The final outcome would be -- instead of a lot of
issues assigned to component leads, we'd have (much) more unassigned
issues, which were *never* looked at. Assigning an issue just sets a
community expectation that a committer should look -- and it does help move
things along!
I think a better approach of addressing the current state would be increase
the number of components / component leads. With more people involved and
lower per-person load, I think we'd be more effective.
Re: [DISCUSSION] Encouraging more contributions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Isma�l,
Honestly, for 4, I think it's not so bad and we clearly improved in the past
months. It's definitely an area where we have to keep improving, but I think we
do a good job (especially comparing to other projects).
For 5, agree. For example, I limit myself to 3 or 4 pull requests: that's why I
have more than 10 local branches waiting.
Regards
JB
On 04/23/2017 10:16 PM, Isma�l Mej�a wrote:
> +1 Great idea Aviem, thanks for bringing this subject to the mailing list.
>
> I agree in particular with the freeing JIRA part, I think we shouldn\u2019t
> keep assigned JIRAs that are things that we don\u2019t expect to solve in
> the next weeks. (note the exception for this are the long features).
>
> I would add two more issues.
>
> 4. We need to react and review code faster for new contributors and
> belp them as much as we can.
>
> I know that this one implies extra work but I have seen many times
> people asking for reviews days after they create a PR and even worse,
> people who have not been able to merge their changes because they were
> dealing with a long code review and then a different PR already
> included changes that fixed the same issue.
>
> 5. We should try to keep the number of open pull requests low.
>
> Our average number of open Pull Requests is continuously increasing
> (current average is 70), There are some PRs in open discussion but
> some are clearly stagnated , maybe we should have like a deadline,
> like if no discussions or improvements were done in the last month we
> must close them and if there is still interest well they will be
> re-opened in that case.
>
> The \u2018good news\u2019 is that we have 350 unassigned unresolved issues that
> anyone can take this is a good improvement but I agree that we can do
> better.
>
> Isma�l
>
>
> On Sun, Apr 23, 2017 at 6:32 AM, Jean-Baptiste Onofr� <jb...@nanthrax.net> wrote:
>> Hi,
>>
>> as we already discussed about that, +1.
>>
>> I would also propose to not assign new Jira automatically: now, the Jira is
>> automatically assigned to the Jira component leader.
>>
>> Regards
>> JB
>>
>>
>> On 04/22/2017 04:31 PM, Aviem Zur wrote:
>>>
>>> Hi all,
>>>
>>> I wanted to start a discussion about actions we can take to encourage more
>>> contributions to the project.
>>>
>>> A few points I've been thinking of:
>>>
>>> 1. Have people unassign themselves from issues they're not actively
>>> working
>>> on.
>>> 2. Have the community engage more in triage, improving tickets
>>> descriptions
>>> and raising concerns.
>>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>>> some can be closed.
>>>
>>> Thoughts? Ideas?
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSSION] Encouraging more contributions
Posted by Ismaël Mejía <ie...@gmail.com>.
+1 Great idea Aviem, thanks for bringing this subject to the mailing list.
I agree in particular with the freeing JIRA part, I think we shouldn’t
keep assigned JIRAs that are things that we don’t expect to solve in
the next weeks. (note the exception for this are the long features).
I would add two more issues.
4. We need to react and review code faster for new contributors and
belp them as much as we can.
I know that this one implies extra work but I have seen many times
people asking for reviews days after they create a PR and even worse,
people who have not been able to merge their changes because they were
dealing with a long code review and then a different PR already
included changes that fixed the same issue.
5. We should try to keep the number of open pull requests low.
Our average number of open Pull Requests is continuously increasing
(current average is 70), There are some PRs in open discussion but
some are clearly stagnated , maybe we should have like a deadline,
like if no discussions or improvements were done in the last month we
must close them and if there is still interest well they will be
re-opened in that case.
The ‘good news’ is that we have 350 unassigned unresolved issues that
anyone can take this is a good improvement but I agree that we can do
better.
Ismaël
On Sun, Apr 23, 2017 at 6:32 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi,
>
> as we already discussed about that, +1.
>
> I would also propose to not assign new Jira automatically: now, the Jira is
> automatically assigned to the Jira component leader.
>
> Regards
> JB
>
>
> On 04/22/2017 04:31 PM, Aviem Zur wrote:
>>
>> Hi all,
>>
>> I wanted to start a discussion about actions we can take to encourage more
>> contributions to the project.
>>
>> A few points I've been thinking of:
>>
>> 1. Have people unassign themselves from issues they're not actively
>> working
>> on.
>> 2. Have the community engage more in triage, improving tickets
>> descriptions
>> and raising concerns.
>> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
>> some can be closed.
>>
>> Thoughts? Ideas?
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [DISCUSSION] Encouraging more contributions
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
as we already discussed about that, +1.
I would also propose to not assign new Jira automatically: now, the Jira is
automatically assigned to the Jira component leader.
Regards
JB
On 04/22/2017 04:31 PM, Aviem Zur wrote:
> Hi all,
>
> I wanted to start a discussion about actions we can take to encourage more
> contributions to the project.
>
> A few points I've been thinking of:
>
> 1. Have people unassign themselves from issues they're not actively working
> on.
> 2. Have the community engage more in triage, improving tickets descriptions
> and raising concerns.
> 3. Clean house - apply (2) to currently open issues (over 800). Perhaps
> some can be closed.
>
> Thoughts? Ideas?
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com