You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Coty Sutherland <cs...@redhat.com> on 2017/05/31 03:07:31 UTC
Things that we can do to increase contributor involvement?
Hi all,
I've been thinking about things that we could do for Tomcat to help
bring in new contributors and to be more appealing to new developers.
Right now we have http://tomcat.apache.org/getinvolved.html which has
a few bullet points and links to documentation, which is a bit verbose,
about how to contribute to an Apache project. We also have the wiki
(https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
about contributing. Bugzilla is a bit daunting for newcomers (thought
we did create the "Beginners" tag to help identify some BZs for new
folks to work on) too. I've been looking around for some ideas on how to
make it easier for new people to contribute after having some
conversations with friends about contributing to Tomcat and found some
interesting examples other projects are using to help bring new people
in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
large of a project as those, but it does have multiple places for
people to contribute (Documentation, Patches, FAQ, wiki, etc) which
could use different skill sets. This site
http://whatcanidoforfedora.org/en would be really cool to implement,
but at the ASF level I think (Tomcat isn't complex enough to warrant
that, is it?).
Anyway, the point of this email is really just to say that we should
take some cues from other projects and try and develop a solid entry
ramp to help entice new developers :) What does everyone else think?
Thanks,
Coty
Re: Things that we can do to increase contributor involvement?
Posted by Mark Thomas <ma...@apache.org>.
On 2 June 2017 15:27:08 BST, Violeta Georgieva <vi...@apache.org> wrote:
>Hi,
>
>2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>
>> Hi all,
>>
>> I've been thinking about things that we could do for Tomcat to help
>> bring in new contributors and to be more appealing to new developers.
>> Right now we have http://tomcat.apache.org/getinvolved.html which has
>> a few bullet points and links to documentation, which is a bit
>verbose,
>> about how to contribute to an Apache project. We also have the wiki
>> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
>> about contributing. Bugzilla is a bit daunting for newcomers (thought
>> we did create the "Beginners" tag to help identify some BZs for new
>> folks to work on) too. I've been looking around for some ideas on how
>to
>> make it easier for new people to contribute after having some
>> conversations with friends about contributing to Tomcat and found
>some
>> interesting examples other projects are using to help bring new
>people
>> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
>> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
>> large of a project as those, but it does have multiple places for
>> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
>> could use different skill sets. This site
>> http://whatcanidoforfedora.org/en would be really cool to implement,
>> but at the ASF level I think (Tomcat isn't complex enough to warrant
>> that, is it?).
>>
>> Anyway, the point of this email is really just to say that we should
>> take some cues from other projects and try and develop a solid entry
>> ramp to help entice new developers :) What does everyone else think?
>
>One thing that might help from my point of view is to provide README.md
>and
>CONTRIBUTING.md for those who are working with GitHub replications of
>the
>repository. It is convenient to have the contribution's instruction
>directly in the root of the repository.
>e.g.
>https://github.com/apache/jmeter/blob/trunk/README.md
>https://github.com/apache/flink/blob/master/README.md
>
>
>What do you think?
+1
Mark
>
>
>Regards,
>Violeta
>>
>>
>> Thanks,
>> Coty
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Coty Sutherland <cs...@redhat.com>.
On Mon, Jun 12, 2017 at 9:39 AM, Coty Sutherland <cs...@redhat.com> wrote:
> On Mon, Jun 12, 2017 at 3:20 AM, Violeta Georgieva <vi...@apache.org> wrote:
>> 2017-06-11 23:57 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>>
>>> On Sun, Jun 11, 2017 at 4:20 PM, Violeta Georgieva <vi...@apache.org>
>> wrote:
>>> > Hi Coty,
>>> >
>>> > 2017-06-02 17:50 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>> >>
>>> >> On Fri, Jun 2, 2017 at 10:27 AM, Violeta Georgieva <
>> violetagg@apache.org>
>>> > wrote:
>>> >> > Hi,
>>> >> >
>>> >> > 2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>> >> >>
>>> >> >> Hi all,
>>> >> >>
>>> >> >> I've been thinking about things that we could do for Tomcat to help
>>> >> >> bring in new contributors and to be more appealing to new
>> developers.
>>> >> >> Right now we have http://tomcat.apache.org/getinvolved.html which
>> has
>>> >> >> a few bullet points and links to documentation, which is a bit
>> verbose,
>>> >> >> about how to contribute to an Apache project. We also have the wiki
>>> >> >> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
>>> >> >> about contributing. Bugzilla is a bit daunting for newcomers
>> (thought
>>> >> >> we did create the "Beginners" tag to help identify some BZs for new
>>> >> >> folks to work on) too. I've been looking around for some ideas on
>> how
>>> > to
>>> >> >> make it easier for new people to contribute after having some
>>> >> >> conversations with friends about contributing to Tomcat and found
>> some
>>> >> >> interesting examples other projects are using to help bring new
>> people
>>> >> >> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
>>> >> >> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
>>> >> >> large of a project as those, but it does have multiple places for
>>> >> >> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
>>> >> >> could use different skill sets. This site
>>> >> >> http://whatcanidoforfedora.org/en would be really cool to implement,
>>> >> >> but at the ASF level I think (Tomcat isn't complex enough to warrant
>>> >> >> that, is it?).
>>> >> >>
>>> >> >> Anyway, the point of this email is really just to say that we should
>>> >> >> take some cues from other projects and try and develop a solid entry
>>> >> >> ramp to help entice new developers :) What does everyone else think?
>>> >> >
>>> >> > One thing that might help from my point of view is to provide
>> README.md
>>> > and
>>> >> > CONTRIBUTING.md for those who are working with GitHub replications of
>>> > the
>>> >> > repository. It is convenient to have the contribution's instruction
>>> >> > directly in the root of the repository.
>>> >> > e.g.
>>> >> > https://github.com/apache/jmeter/blob/trunk/README.md
>>> >> > https://github.com/apache/flink/blob/master/README.md
>>> >> >
>>> >> >
>>> >> > What do you think?
>>> >>
>>> >> Oh yeah. That's a great idea! I was just catching up on the thread and
>>> >> was trying to think of a way a way to let github users know what
>>> >> committers are doing with their PRs to get them committed (a README is
>>> >> obvious). I think that adding some transparency there may help them
>>> >> understand some issues that could cause latency.
>>> >>
>>> >
>>> > If you didn't start with README.md I can prepare some initial version.
>>>
>>> I hadn't started yet, but I intended to. It's on my TODO list :)
>>
>> Ok I'll leave it to you ;)
OK, published (what I think is) a solid first draft :) Now that
something is there, I'm sure everyone has ideas on what it needs to
be. Feel free to edit as needed. I tried to make the tone a bit jovial
so that it's a bit less daunting and more welcoming for new folks.
Cheers,
> Sounds good. I'm working on it now and should be committing the two
> files shortly in trunk for review. After I get some positive feedback
> then I'll port to 7, 8, and 8.5. I was going to try and make them
> generic documents, however since the branches are all in separate git
> repos anyway I'm adding some version specific information.
>
>> Violeta
>>
>>> If you want, you can put something up and I'll edit it as soon as I make
>>> time.
>>>
>>> > Regards,
>>> > Violeta
>>> >
>>> >> > Regards,
>>> >> > Violeta
>>> >> >>
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Coty
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> >> For additional commands, e-mail: dev-help@tomcat.apache.org
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Coty Sutherland <cs...@redhat.com>.
On Mon, Jun 12, 2017 at 3:20 AM, Violeta Georgieva <vi...@apache.org> wrote:
> 2017-06-11 23:57 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>
>> On Sun, Jun 11, 2017 at 4:20 PM, Violeta Georgieva <vi...@apache.org>
> wrote:
>> > Hi Coty,
>> >
>> > 2017-06-02 17:50 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>> >>
>> >> On Fri, Jun 2, 2017 at 10:27 AM, Violeta Georgieva <
> violetagg@apache.org>
>> > wrote:
>> >> > Hi,
>> >> >
>> >> > 2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> I've been thinking about things that we could do for Tomcat to help
>> >> >> bring in new contributors and to be more appealing to new
> developers.
>> >> >> Right now we have http://tomcat.apache.org/getinvolved.html which
> has
>> >> >> a few bullet points and links to documentation, which is a bit
> verbose,
>> >> >> about how to contribute to an Apache project. We also have the wiki
>> >> >> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
>> >> >> about contributing. Bugzilla is a bit daunting for newcomers
> (thought
>> >> >> we did create the "Beginners" tag to help identify some BZs for new
>> >> >> folks to work on) too. I've been looking around for some ideas on
> how
>> > to
>> >> >> make it easier for new people to contribute after having some
>> >> >> conversations with friends about contributing to Tomcat and found
> some
>> >> >> interesting examples other projects are using to help bring new
> people
>> >> >> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
>> >> >> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
>> >> >> large of a project as those, but it does have multiple places for
>> >> >> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
>> >> >> could use different skill sets. This site
>> >> >> http://whatcanidoforfedora.org/en would be really cool to implement,
>> >> >> but at the ASF level I think (Tomcat isn't complex enough to warrant
>> >> >> that, is it?).
>> >> >>
>> >> >> Anyway, the point of this email is really just to say that we should
>> >> >> take some cues from other projects and try and develop a solid entry
>> >> >> ramp to help entice new developers :) What does everyone else think?
>> >> >
>> >> > One thing that might help from my point of view is to provide
> README.md
>> > and
>> >> > CONTRIBUTING.md for those who are working with GitHub replications of
>> > the
>> >> > repository. It is convenient to have the contribution's instruction
>> >> > directly in the root of the repository.
>> >> > e.g.
>> >> > https://github.com/apache/jmeter/blob/trunk/README.md
>> >> > https://github.com/apache/flink/blob/master/README.md
>> >> >
>> >> >
>> >> > What do you think?
>> >>
>> >> Oh yeah. That's a great idea! I was just catching up on the thread and
>> >> was trying to think of a way a way to let github users know what
>> >> committers are doing with their PRs to get them committed (a README is
>> >> obvious). I think that adding some transparency there may help them
>> >> understand some issues that could cause latency.
>> >>
>> >
>> > If you didn't start with README.md I can prepare some initial version.
>>
>> I hadn't started yet, but I intended to. It's on my TODO list :)
>
> Ok I'll leave it to you ;)
Sounds good. I'm working on it now and should be committing the two
files shortly in trunk for review. After I get some positive feedback
then I'll port to 7, 8, and 8.5. I was going to try and make them
generic documents, however since the branches are all in separate git
repos anyway I'm adding some version specific information.
> Violeta
>
>> If you want, you can put something up and I'll edit it as soon as I make
>> time.
>>
>> > Regards,
>> > Violeta
>> >
>> >> > Regards,
>> >> > Violeta
>> >> >>
>> >> >>
>> >> >> Thanks,
>> >> >> Coty
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> >> For additional commands, e-mail: dev-help@tomcat.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Violeta Georgieva <vi...@apache.org>.
2017-06-11 23:57 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>
> On Sun, Jun 11, 2017 at 4:20 PM, Violeta Georgieva <vi...@apache.org>
wrote:
> > Hi Coty,
> >
> > 2017-06-02 17:50 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
> >>
> >> On Fri, Jun 2, 2017 at 10:27 AM, Violeta Georgieva <
violetagg@apache.org>
> > wrote:
> >> > Hi,
> >> >
> >> > 2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I've been thinking about things that we could do for Tomcat to help
> >> >> bring in new contributors and to be more appealing to new
developers.
> >> >> Right now we have http://tomcat.apache.org/getinvolved.html which
has
> >> >> a few bullet points and links to documentation, which is a bit
verbose,
> >> >> about how to contribute to an Apache project. We also have the wiki
> >> >> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
> >> >> about contributing. Bugzilla is a bit daunting for newcomers
(thought
> >> >> we did create the "Beginners" tag to help identify some BZs for new
> >> >> folks to work on) too. I've been looking around for some ideas on
how
> > to
> >> >> make it easier for new people to contribute after having some
> >> >> conversations with friends about contributing to Tomcat and found
some
> >> >> interesting examples other projects are using to help bring new
people
> >> >> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
> >> >> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
> >> >> large of a project as those, but it does have multiple places for
> >> >> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
> >> >> could use different skill sets. This site
> >> >> http://whatcanidoforfedora.org/en would be really cool to implement,
> >> >> but at the ASF level I think (Tomcat isn't complex enough to warrant
> >> >> that, is it?).
> >> >>
> >> >> Anyway, the point of this email is really just to say that we should
> >> >> take some cues from other projects and try and develop a solid entry
> >> >> ramp to help entice new developers :) What does everyone else think?
> >> >
> >> > One thing that might help from my point of view is to provide
README.md
> > and
> >> > CONTRIBUTING.md for those who are working with GitHub replications of
> > the
> >> > repository. It is convenient to have the contribution's instruction
> >> > directly in the root of the repository.
> >> > e.g.
> >> > https://github.com/apache/jmeter/blob/trunk/README.md
> >> > https://github.com/apache/flink/blob/master/README.md
> >> >
> >> >
> >> > What do you think?
> >>
> >> Oh yeah. That's a great idea! I was just catching up on the thread and
> >> was trying to think of a way a way to let github users know what
> >> committers are doing with their PRs to get them committed (a README is
> >> obvious). I think that adding some transparency there may help them
> >> understand some issues that could cause latency.
> >>
> >
> > If you didn't start with README.md I can prepare some initial version.
>
> I hadn't started yet, but I intended to. It's on my TODO list :)
Ok I'll leave it to you ;)
Violeta
> If you want, you can put something up and I'll edit it as soon as I make
> time.
>
> > Regards,
> > Violeta
> >
> >> > Regards,
> >> > Violeta
> >> >>
> >> >>
> >> >> Thanks,
> >> >> Coty
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: Things that we can do to increase contributor involvement?
Posted by Coty Sutherland <cs...@redhat.com>.
On Sun, Jun 11, 2017 at 4:20 PM, Violeta Georgieva <vi...@apache.org> wrote:
> Hi Coty,
>
> 2017-06-02 17:50 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>
>> On Fri, Jun 2, 2017 at 10:27 AM, Violeta Georgieva <vi...@apache.org>
> wrote:
>> > Hi,
>> >
>> > 2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>> >>
>> >> Hi all,
>> >>
>> >> I've been thinking about things that we could do for Tomcat to help
>> >> bring in new contributors and to be more appealing to new developers.
>> >> Right now we have http://tomcat.apache.org/getinvolved.html which has
>> >> a few bullet points and links to documentation, which is a bit verbose,
>> >> about how to contribute to an Apache project. We also have the wiki
>> >> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
>> >> about contributing. Bugzilla is a bit daunting for newcomers (thought
>> >> we did create the "Beginners" tag to help identify some BZs for new
>> >> folks to work on) too. I've been looking around for some ideas on how
> to
>> >> make it easier for new people to contribute after having some
>> >> conversations with friends about contributing to Tomcat and found some
>> >> interesting examples other projects are using to help bring new people
>> >> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
>> >> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
>> >> large of a project as those, but it does have multiple places for
>> >> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
>> >> could use different skill sets. This site
>> >> http://whatcanidoforfedora.org/en would be really cool to implement,
>> >> but at the ASF level I think (Tomcat isn't complex enough to warrant
>> >> that, is it?).
>> >>
>> >> Anyway, the point of this email is really just to say that we should
>> >> take some cues from other projects and try and develop a solid entry
>> >> ramp to help entice new developers :) What does everyone else think?
>> >
>> > One thing that might help from my point of view is to provide README.md
> and
>> > CONTRIBUTING.md for those who are working with GitHub replications of
> the
>> > repository. It is convenient to have the contribution's instruction
>> > directly in the root of the repository.
>> > e.g.
>> > https://github.com/apache/jmeter/blob/trunk/README.md
>> > https://github.com/apache/flink/blob/master/README.md
>> >
>> >
>> > What do you think?
>>
>> Oh yeah. That's a great idea! I was just catching up on the thread and
>> was trying to think of a way a way to let github users know what
>> committers are doing with their PRs to get them committed (a README is
>> obvious). I think that adding some transparency there may help them
>> understand some issues that could cause latency.
>>
>
> If you didn't start with README.md I can prepare some initial version.
I hadn't started yet, but I intended to. It's on my TODO list :) If
you want, you can put something up and I'll edit it as soon as I make
time.
> Regards,
> Violeta
>
>> > Regards,
>> > Violeta
>> >>
>> >>
>> >> Thanks,
>> >> Coty
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Violeta Georgieva <vi...@apache.org>.
Hi Coty,
2017-06-02 17:50 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>
> On Fri, Jun 2, 2017 at 10:27 AM, Violeta Georgieva <vi...@apache.org>
wrote:
> > Hi,
> >
> > 2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
> >>
> >> Hi all,
> >>
> >> I've been thinking about things that we could do for Tomcat to help
> >> bring in new contributors and to be more appealing to new developers.
> >> Right now we have http://tomcat.apache.org/getinvolved.html which has
> >> a few bullet points and links to documentation, which is a bit verbose,
> >> about how to contribute to an Apache project. We also have the wiki
> >> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
> >> about contributing. Bugzilla is a bit daunting for newcomers (thought
> >> we did create the "Beginners" tag to help identify some BZs for new
> >> folks to work on) too. I've been looking around for some ideas on how
to
> >> make it easier for new people to contribute after having some
> >> conversations with friends about contributing to Tomcat and found some
> >> interesting examples other projects are using to help bring new people
> >> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
> >> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
> >> large of a project as those, but it does have multiple places for
> >> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
> >> could use different skill sets. This site
> >> http://whatcanidoforfedora.org/en would be really cool to implement,
> >> but at the ASF level I think (Tomcat isn't complex enough to warrant
> >> that, is it?).
> >>
> >> Anyway, the point of this email is really just to say that we should
> >> take some cues from other projects and try and develop a solid entry
> >> ramp to help entice new developers :) What does everyone else think?
> >
> > One thing that might help from my point of view is to provide README.md
and
> > CONTRIBUTING.md for those who are working with GitHub replications of
the
> > repository. It is convenient to have the contribution's instruction
> > directly in the root of the repository.
> > e.g.
> > https://github.com/apache/jmeter/blob/trunk/README.md
> > https://github.com/apache/flink/blob/master/README.md
> >
> >
> > What do you think?
>
> Oh yeah. That's a great idea! I was just catching up on the thread and
> was trying to think of a way a way to let github users know what
> committers are doing with their PRs to get them committed (a README is
> obvious). I think that adding some transparency there may help them
> understand some issues that could cause latency.
>
If you didn't start with README.md I can prepare some initial version.
Regards,
Violeta
> > Regards,
> > Violeta
> >>
> >>
> >> Thanks,
> >> Coty
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
Re: Things that we can do to increase contributor involvement?
Posted by Coty Sutherland <cs...@redhat.com>.
On Fri, Jun 2, 2017 at 10:27 AM, Violeta Georgieva <vi...@apache.org> wrote:
> Hi,
>
> 2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>>
>> Hi all,
>>
>> I've been thinking about things that we could do for Tomcat to help
>> bring in new contributors and to be more appealing to new developers.
>> Right now we have http://tomcat.apache.org/getinvolved.html which has
>> a few bullet points and links to documentation, which is a bit verbose,
>> about how to contribute to an Apache project. We also have the wiki
>> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
>> about contributing. Bugzilla is a bit daunting for newcomers (thought
>> we did create the "Beginners" tag to help identify some BZs for new
>> folks to work on) too. I've been looking around for some ideas on how to
>> make it easier for new people to contribute after having some
>> conversations with friends about contributing to Tomcat and found some
>> interesting examples other projects are using to help bring new people
>> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
>> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
>> large of a project as those, but it does have multiple places for
>> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
>> could use different skill sets. This site
>> http://whatcanidoforfedora.org/en would be really cool to implement,
>> but at the ASF level I think (Tomcat isn't complex enough to warrant
>> that, is it?).
>>
>> Anyway, the point of this email is really just to say that we should
>> take some cues from other projects and try and develop a solid entry
>> ramp to help entice new developers :) What does everyone else think?
>
> One thing that might help from my point of view is to provide README.md and
> CONTRIBUTING.md for those who are working with GitHub replications of the
> repository. It is convenient to have the contribution's instruction
> directly in the root of the repository.
> e.g.
> https://github.com/apache/jmeter/blob/trunk/README.md
> https://github.com/apache/flink/blob/master/README.md
>
>
> What do you think?
Oh yeah. That's a great idea! I was just catching up on the thread and
was trying to think of a way a way to let github users know what
committers are doing with their PRs to get them committed (a README is
obvious). I think that adding some transparency there may help them
understand some issues that could cause latency.
> Regards,
> Violeta
>>
>>
>> Thanks,
>> Coty
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Violeta Georgieva <vi...@apache.org>.
Hi,
2017-05-31 6:07 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
>
> Hi all,
>
> I've been thinking about things that we could do for Tomcat to help
> bring in new contributors and to be more appealing to new developers.
> Right now we have http://tomcat.apache.org/getinvolved.html which has
> a few bullet points and links to documentation, which is a bit verbose,
> about how to contribute to an Apache project. We also have the wiki
> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
> about contributing. Bugzilla is a bit daunting for newcomers (thought
> we did create the "Beginners" tag to help identify some BZs for new
> folks to work on) too. I've been looking around for some ideas on how to
> make it easier for new people to contribute after having some
> conversations with friends about contributing to Tomcat and found some
> interesting examples other projects are using to help bring new people
> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
> large of a project as those, but it does have multiple places for
> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
> could use different skill sets. This site
> http://whatcanidoforfedora.org/en would be really cool to implement,
> but at the ASF level I think (Tomcat isn't complex enough to warrant
> that, is it?).
>
> Anyway, the point of this email is really just to say that we should
> take some cues from other projects and try and develop a solid entry
> ramp to help entice new developers :) What does everyone else think?
One thing that might help from my point of view is to provide README.md and
CONTRIBUTING.md for those who are working with GitHub replications of the
repository. It is convenient to have the contribution's instruction
directly in the root of the repository.
e.g.
https://github.com/apache/jmeter/blob/trunk/README.md
https://github.com/apache/flink/blob/master/README.md
What do you think?
Regards,
Violeta
>
>
> Thanks,
> Coty
Re: Things that we can do to increase contributor involvement?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2017-06-01 15:05 GMT+03:00 Coty Sutherland <cs...@redhat.com>:
> Hi,
>
> On Wed, May 31, 2017 at 12:08 PM, Igal @ Lucee.org <ig...@lucee.org> wrote:
>> Hi all,
>>
>> On 5/31/2017 1:12 AM, Mark Thomas wrote:
>>>
>>> On 31/05/17 04:07, Coty Sutherland wrote:
>>>>
>>>> I've been thinking about things that we could do for Tomcat to help
>>>> bring in new contributors and to be more appealing to new developers.
>>>
>>> https://helpwanted.apache.org/
>>
>>
>> I would like to offer the perspective of the "new contributor" here. I, for
>> one, would love to contribute and be more involved with the Tomcat project,
>> and I believe that thanks to Tomcat's popularity there are many out there
>> just like me.
>>
>> As a new contributor, the most important thing is to get some feedback. The
>> "worst" thing from a new contributor's perspective is that he/she will put
>> much time into work that will never be looked at, and all that time will go
>> to waste.
>
> I agree :) Thanks for the feedback. By voicing concerns like these we
> can get them addressed.
>
>> We understand that not all contributions will be accepted, and that they
>> must adhere to the standards set by the project. We also realize that this
>> is open source, and that the people who review the submission are usually
>> volunteers who do the best they can in the time that they can afford to
>> contribute to the project.
>>
>> We still need, however, to get some feedback on our submitted work in a
>> timely manner before we can try again, or submit some other work.
1. Do you read dev@tomcat ?
Do you review others' commits?
Do you test release candidates?
For me, new contributions come after that.
>> Take for example the PRs on Github (sorry, but SVN feels like the 1980s --
>> great time for partying, not so much for writing code -- and I know,
>> ironically the SVN project started in 2000, but I digress):
>> https://github.com/apache/tomcat/pulls
>
> Hm, using Git was mentioned at the TomcatCon but I can't recall if the
> git repository on github is bi-directional or just a clone of svn. Can
> anyone answer that?
2. ASF Git repository is read-only mirror of svn repository.
Github repository is mirror of ASF Git repository.
It is possible to use git-svn bridge to commit to svn with git commands
(git-svn metadata are present in commits and it is possible),
but I prefer to overlap git checkout over svn working copy
and commit with svn.
This way it is easier to review.
> Have we made a decision about the best way to
> submit patches? BZ attachment, github PR, email, other? How often do
> we check the github projects for contributions?
3. The work-to-do is tracked via Bugzilla.
The changelog file references Bugzilla.
Thus it is better when a PR references a Bugzilla issue.
For me, PRs are equivalent to attached patches.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Thu, Jun 1, 2017 at 3:34 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi guys,
>
> a quick feedback on that topic:
>
> - github seems to be the preferred way to submit code these days (what we
> saw in tomee, batchee etc), it implies almost the same amount of work for
> dev (just need to comment if applied or not on github itself for tracking)
> so it is a good way probably
> - tomcat build not being "standard" can be a stopper for newcomers, I know
> migrating to a real maven structure was rejected multiple times but I think
> it can help. It would enable to import the project smoothly in any IDE, run
> it almost directly from the command line (it is not rare now to not have
> ant), and make it easier to browse the structure/package/module
>
I totally agree with Romain here!
I have said it before as well: http://markmail.org/message/aomihwix7bvxpttd
@Konstantin: re. "PR === patch"
For me PR is much more convenient than a .patch file because I can comment
on any line! And even have a whole discussion thread on it!
Me and some other ASF committers have asked at
users@infrastructure.apache.org why ASF Git doesn't provide more advanced
features, like PRs. Even Atlassian offered hosted BitBucket for free but it
has been rejected :-/
Now there is https://gitbox.apache.org/ but it is still in early evaluation
stage. I hope it will make it simpler for my other Apache projects (Wicket
and Isis) some day!
Martin
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/
> rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-06-01 15:29 GMT+02:00 Mark Thomas <ma...@apache.org>:
>
> > On 1 June 2017 13:05:18 BST, Coty Sutherland <cs...@redhat.com>
> wrote:
> >
> > >Hm, using Git was mentioned at the TomcatCon but I can't recall if the
> > >git repository on github is bi-directional or just a clone of svn. Can
> > >anyone answer that?
> >
> > The ASF hosts a read-only git clone of svn. GitHub has a read-only mirror
> > of the ASF repo.
> >
> > I.e. only ASF svn is read/write.
> >
> > > Have we made a decision about the best way to
> > >submit patches? BZ attachment, github PR, email, other?
> >
> > BZ or PR are generally best since they are less likely to be forgotten.
> >
> > > How often do
> > >we check the github projects for contributions?
> >
> > Notifications of PRs get sent to the dev list.
> >
> > > We also talked about
> > >going over the tomcat 6 and older version BZs to clean them up, maybe
> > >we should do the same for github PRs?
> >
> > 5.5.x and earlier was cleaned up as they went EOL. There are currently 15
> > or so 6.0.x BZ entries left to clean up.
> >
> > >> Anyway, there are PRs there from a few months ago, all the way to a
> > >couple
> > >> of years ago. The really old ones should be closed IMO, and suggest
> > >to the
> > >> contributors to submit again if the issue(s) are still valid.
> >
> > There is generally a large difference in responsiveness between bugs and
> > enhancement requests. Most of the open PRs have been reviewed and are
> > waiting for feedback. The others are enhancement requests which typically
> > remain open until there is sufficient interest in implementing them.
> >
> > Yes it would be great to move faster on these. That needs more people
> > looking at them. Things are slowly improving - the total open issues is
> > trending downwards over time.
> >
> > Mark
> >
> >
> > > The
> > >newer
> > >> ones should be evaluated and feedback should be given to the
> > >contributors
> > >> You already "found" new contributors -- better spend some time
> > >"cultivating"
> > >> them than look for new ones who might end up stuck in that same
> > >situation.
> > >>
> > >> The most recent PR ATM -- https://github.com/apache/tomcat/pull/56 --
> > >is
> > >> from me, and it's only been a few days, so normally I wouldn't have
> > >said
> > >> anything at this point because it hasn't been "long enough" since I
> > >> submitted it. But then I saw this email and it made perfect sense
> > >for me to
> > >> chime in.
> > >>
> > >> It was very important for me to keep my PR as small and simple as
> > >possible,
> > >> so that it's easy to review and accept or reject. But there is no
> > >feedback
> > >
> > >Just for future reference, when you submit a PR it's easiest to review
> > >if you squash all of the commits into one rather than multiple
> > >commits.
> > >
> > >> whatsoever. I usually have more time to contribute on the weekends,
> > >so if
> > >> I'll get some feedback soon, I will hopefully be able to implement
> > >whatever
> > >> changes necessary on the weekend. If not, then another week goes by.
> > >>
> > >> Anyway, I really am not complaining here. Just providing a
> > >perspective from
> > >> "the other side".
> > >>
> > >> All the best, and keep up the good work!
> > >
> > >I appreciate the perspective and hope to hear more from new
> > >contributors :) Thanks again!
> > >
> > >> Igal
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >> For additional commands, e-mail: dev-help@tomcat.apache.org
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > >For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
Re: Things that we can do to increase contributor involvement?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi guys,
a quick feedback on that topic:
- github seems to be the preferred way to submit code these days (what we
saw in tomee, batchee etc), it implies almost the same amount of work for
dev (just need to comment if applied or not on github itself for tracking)
so it is a good way probably
- tomcat build not being "standard" can be a stopper for newcomers, I know
migrating to a real maven structure was rejected multiple times but I think
it can help. It would enable to import the project smoothly in any IDE, run
it almost directly from the command line (it is not rare now to not have
ant), and make it easier to browse the structure/package/module
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-06-01 15:29 GMT+02:00 Mark Thomas <ma...@apache.org>:
> On 1 June 2017 13:05:18 BST, Coty Sutherland <cs...@redhat.com> wrote:
>
> >Hm, using Git was mentioned at the TomcatCon but I can't recall if the
> >git repository on github is bi-directional or just a clone of svn. Can
> >anyone answer that?
>
> The ASF hosts a read-only git clone of svn. GitHub has a read-only mirror
> of the ASF repo.
>
> I.e. only ASF svn is read/write.
>
> > Have we made a decision about the best way to
> >submit patches? BZ attachment, github PR, email, other?
>
> BZ or PR are generally best since they are less likely to be forgotten.
>
> > How often do
> >we check the github projects for contributions?
>
> Notifications of PRs get sent to the dev list.
>
> > We also talked about
> >going over the tomcat 6 and older version BZs to clean them up, maybe
> >we should do the same for github PRs?
>
> 5.5.x and earlier was cleaned up as they went EOL. There are currently 15
> or so 6.0.x BZ entries left to clean up.
>
> >> Anyway, there are PRs there from a few months ago, all the way to a
> >couple
> >> of years ago. The really old ones should be closed IMO, and suggest
> >to the
> >> contributors to submit again if the issue(s) are still valid.
>
> There is generally a large difference in responsiveness between bugs and
> enhancement requests. Most of the open PRs have been reviewed and are
> waiting for feedback. The others are enhancement requests which typically
> remain open until there is sufficient interest in implementing them.
>
> Yes it would be great to move faster on these. That needs more people
> looking at them. Things are slowly improving - the total open issues is
> trending downwards over time.
>
> Mark
>
>
> > The
> >newer
> >> ones should be evaluated and feedback should be given to the
> >contributors
> >> You already "found" new contributors -- better spend some time
> >"cultivating"
> >> them than look for new ones who might end up stuck in that same
> >situation.
> >>
> >> The most recent PR ATM -- https://github.com/apache/tomcat/pull/56 --
> >is
> >> from me, and it's only been a few days, so normally I wouldn't have
> >said
> >> anything at this point because it hasn't been "long enough" since I
> >> submitted it. But then I saw this email and it made perfect sense
> >for me to
> >> chime in.
> >>
> >> It was very important for me to keep my PR as small and simple as
> >possible,
> >> so that it's easy to review and accept or reject. But there is no
> >feedback
> >
> >Just for future reference, when you submit a PR it's easiest to review
> >if you squash all of the commits into one rather than multiple
> >commits.
> >
> >> whatsoever. I usually have more time to contribute on the weekends,
> >so if
> >> I'll get some feedback soon, I will hopefully be able to implement
> >whatever
> >> changes necessary on the weekend. If not, then another week goes by.
> >>
> >> Anyway, I really am not complaining here. Just providing a
> >perspective from
> >> "the other side".
> >>
> >> All the best, and keep up the good work!
> >
> >I appreciate the perspective and hope to hear more from new
> >contributors :) Thanks again!
> >
> >> Igal
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Things that we can do to increase contributor involvement?
Posted by "Igal @ Lucee.org" <ig...@lucee.org>.
Chris,
On 6/1/2017 11:16 AM, Christopher Schultz wrote:
> Just remember that everyone here is a volunteer, and it takes much
> longer to review/test a patch/PR than it does to e.g. reply to a message
> on a mailing list. We all have our primary jobs and our families and
> both of those take priority over volunteering for the ASF and its
> communities.
I'm not sure if you read my first email in this thread (reading emails
is also very time consuming, I know), but I made it very clear there
that I am aware of these factors and that I set my expectations
accordingly. I wouldn't have even mentioned my PR at this point if it
weren't for Coty's email which started this thread.
I believe that my perspective represents most new contributors, and not
only my own personal views, and that's the reason I posted it.
> We always say "patches are always welcome" but, you're right, if the
> patches sit unreviewed for a long time, it's tough to feel like your
> contributions are valued.
I have been contributing to various open source projects for the better
part of a decade now. Unfortunately, in the beginning, I had submitted
large PRs a few times, that contained a lot of work. That work was not
reviewed in a timely manner, and at some point the code base has changed
so much that it was un-mergeable anymore, leading to loss of time and
effort.
I have learned since to submit smaller and cleaner patches, so that they
are easier to review. But still, if they are not reviewed in a timely
manner there is: 1) a risk of them becoming unmergable due to changes in
the code base; and 2) discouragement of the submitter from doing more work.
> -chris
If that really is your name... Christopher Schultz signs his messages
with a PGP signature ;)
Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>
Re: Things that we can do to increase contributor involvement?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Igal,
On 6/1/17 1:59 PM, Igal @ Lucee.org wrote:
> On 6/1/2017 5:05 AM, Coty Sutherland wrote:
>>
>> Just for future reference, when you submit a PR it's easiest to review
>> if you squash all of the commits into one rather than multiple
>> commits.
>
> Perhaps that's a mentality difference between SVN users and git users.
> In git it is common to do as in voting: commit early and commit often (
> https://en.wikipedia.org/wiki/Vote_early_and_vote_often ).
>
> But there is a very simple solution for that -- rather than check the
> individual commits, check the "Files changed" tab in github, in this
> case https://github.com/apache/tomcat/pull/56/files (notice `files`
> added to endpoint, but clicking the tab would take you there directly).
>
> That shows the cumulative changes of all of the commits.
>
> I try to make my PRs as easy as possible to review.
>
> On 6/1/2017 6:29 AM, Mark Thomas wrote:
>>>> There is generally a large difference in responsiveness between bugs
>>>> and enhancement requests. Most of the open PRs have been reviewed
>>>> and are waiting for feedback. The others are enhancement requests
>>>> which typically remain open until there is sufficient interest in
>>>> implementing them.
>
> Understandable, but please bear in mind that new contributors can not
> usually start with complicated bugs. The new "Newbie / Stater /
> Beginner" keyword that you added to BZ was a great idea (h/t Chris), but
> if "Beginner" issues will not be reviewed due to lack of interest, then
> new contributors are very unlikely to submit any PRs after that first
> one that will not be addressed.
>
> If Tomcat wants new contributors (and it should!), then a better
> feedback loop is required.
>
> I, for one, am excited to contribute more to the project. I've already
> received some feedback from Violeta about my PR since I sent my last
> email, and updated the PR accordingly. I'm not sure if this thread had
> triggered the review or not, but AFAIC this is good progress :)
All good points.
Just remember that everyone here is a volunteer, and it takes much
longer to review/test a patch/PR than it does to e.g. reply to a message
on a mailing list. We all have our primary jobs and our families and
both of those take priority over volunteering for the ASF and its
communities.
If you aren't getting enough feedback, don't hesitate to post to the
mailing list to "remind" everyone that you have a pending patch/PR and
that you'd appreciate some feedback.
We always say "patches are always welcome" but, you're right, if the
patches sit unreviewed for a long time, it's tough to feel like your
contributions are valued.
-chris
Re: Things that we can do to increase contributor involvement?
Posted by "Igal @ Lucee.org" <ig...@lucee.org>.
On 6/1/2017 5:05 AM, Coty Sutherland wrote:
>
> Just for future reference, when you submit a PR it's easiest to review
> if you squash all of the commits into one rather than multiple
> commits.
Perhaps that's a mentality difference between SVN users and git users.
In git it is common to do as in voting: commit early and commit often (
https://en.wikipedia.org/wiki/Vote_early_and_vote_often ).
But there is a very simple solution for that -- rather than check the
individual commits, check the "Files changed" tab in github, in this
case https://github.com/apache/tomcat/pull/56/files (notice `files`
added to endpoint, but clicking the tab would take you there directly).
That shows the cumulative changes of all of the commits.
I try to make my PRs as easy as possible to review.
On 6/1/2017 6:29 AM, Mark Thomas wrote:
>>> There is generally a large difference in responsiveness between bugs and enhancement requests. Most of the open PRs have been reviewed and are waiting for feedback. The others are enhancement requests which typically remain open until there is sufficient interest in implementing them.
Understandable, but please bear in mind that new contributors can not
usually start with complicated bugs. The new "Newbie / Stater /
Beginner" keyword that you added to BZ was a great idea (h/t Chris), but
if "Beginner" issues will not be reviewed due to lack of interest, then
new contributors are very unlikely to submit any PRs after that first
one that will not be addressed.
If Tomcat wants new contributors (and it should!), then a better
feedback loop is required.
I, for one, am excited to contribute more to the project. I've already
received some feedback from Violeta about my PR since I sent my last
email, and updated the PR accordingly. I'm not sure if this thread had
triggered the review or not, but AFAIC this is good progress :)
Igal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Mark Thomas <ma...@apache.org>.
On 1 June 2017 13:05:18 BST, Coty Sutherland <cs...@redhat.com> wrote:
>Hm, using Git was mentioned at the TomcatCon but I can't recall if the
>git repository on github is bi-directional or just a clone of svn. Can
>anyone answer that?
The ASF hosts a read-only git clone of svn. GitHub has a read-only mirror of the ASF repo.
I.e. only ASF svn is read/write.
> Have we made a decision about the best way to
>submit patches? BZ attachment, github PR, email, other?
BZ or PR are generally best since they are less likely to be forgotten.
> How often do
>we check the github projects for contributions?
Notifications of PRs get sent to the dev list.
> We also talked about
>going over the tomcat 6 and older version BZs to clean them up, maybe
>we should do the same for github PRs?
5.5.x and earlier was cleaned up as they went EOL. There are currently 15 or so 6.0.x BZ entries left to clean up.
>> Anyway, there are PRs there from a few months ago, all the way to a
>couple
>> of years ago. The really old ones should be closed IMO, and suggest
>to the
>> contributors to submit again if the issue(s) are still valid.
There is generally a large difference in responsiveness between bugs and enhancement requests. Most of the open PRs have been reviewed and are waiting for feedback. The others are enhancement requests which typically remain open until there is sufficient interest in implementing them.
Yes it would be great to move faster on these. That needs more people looking at them. Things are slowly improving - the total open issues is trending downwards over time.
Mark
> The
>newer
>> ones should be evaluated and feedback should be given to the
>contributors
>> You already "found" new contributors -- better spend some time
>"cultivating"
>> them than look for new ones who might end up stuck in that same
>situation.
>>
>> The most recent PR ATM -- https://github.com/apache/tomcat/pull/56 --
>is
>> from me, and it's only been a few days, so normally I wouldn't have
>said
>> anything at this point because it hasn't been "long enough" since I
>> submitted it. But then I saw this email and it made perfect sense
>for me to
>> chime in.
>>
>> It was very important for me to keep my PR as small and simple as
>possible,
>> so that it's easy to review and accept or reject. But there is no
>feedback
>
>Just for future reference, when you submit a PR it's easiest to review
>if you squash all of the commits into one rather than multiple
>commits.
>
>> whatsoever. I usually have more time to contribute on the weekends,
>so if
>> I'll get some feedback soon, I will hopefully be able to implement
>whatever
>> changes necessary on the weekend. If not, then another week goes by.
>>
>> Anyway, I really am not complaining here. Just providing a
>perspective from
>> "the other side".
>>
>> All the best, and keep up the good work!
>
>I appreciate the perspective and hope to hear more from new
>contributors :) Thanks again!
>
>> Igal
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Coty Sutherland <cs...@redhat.com>.
Hi,
On Wed, May 31, 2017 at 12:08 PM, Igal @ Lucee.org <ig...@lucee.org> wrote:
> Hi all,
>
> On 5/31/2017 1:12 AM, Mark Thomas wrote:
>>
>> On 31/05/17 04:07, Coty Sutherland wrote:
>>>
>>> I've been thinking about things that we could do for Tomcat to help
>>> bring in new contributors and to be more appealing to new developers.
>>
>> https://helpwanted.apache.org/
>
>
> I would like to offer the perspective of the "new contributor" here. I, for
> one, would love to contribute and be more involved with the Tomcat project,
> and I believe that thanks to Tomcat's popularity there are many out there
> just like me.
>
> As a new contributor, the most important thing is to get some feedback. The
> "worst" thing from a new contributor's perspective is that he/she will put
> much time into work that will never be looked at, and all that time will go
> to waste.
I agree :) Thanks for the feedback. By voicing concerns like these we
can get them addressed.
> We understand that not all contributions will be accepted, and that they
> must adhere to the standards set by the project. We also realize that this
> is open source, and that the people who review the submission are usually
> volunteers who do the best they can in the time that they can afford to
> contribute to the project.
>
> We still need, however, to get some feedback on our submitted work in a
> timely manner before we can try again, or submit some other work.
>
> Take for example the PRs on Github (sorry, but SVN feels like the 1980s --
> great time for partying, not so much for writing code -- and I know,
> ironically the SVN project started in 2000, but I digress):
> https://github.com/apache/tomcat/pulls
Hm, using Git was mentioned at the TomcatCon but I can't recall if the
git repository on github is bi-directional or just a clone of svn. Can
anyone answer that? Have we made a decision about the best way to
submit patches? BZ attachment, github PR, email, other? How often do
we check the github projects for contributions? We also talked about
going over the tomcat 6 and older version BZs to clean them up, maybe
we should do the same for github PRs?
> Anyway, there are PRs there from a few months ago, all the way to a couple
> of years ago. The really old ones should be closed IMO, and suggest to the
> contributors to submit again if the issue(s) are still valid. The newer
> ones should be evaluated and feedback should be given to the contributors
> You already "found" new contributors -- better spend some time "cultivating"
> them than look for new ones who might end up stuck in that same situation.
>
> The most recent PR ATM -- https://github.com/apache/tomcat/pull/56 -- is
> from me, and it's only been a few days, so normally I wouldn't have said
> anything at this point because it hasn't been "long enough" since I
> submitted it. But then I saw this email and it made perfect sense for me to
> chime in.
>
> It was very important for me to keep my PR as small and simple as possible,
> so that it's easy to review and accept or reject. But there is no feedback
Just for future reference, when you submit a PR it's easiest to review
if you squash all of the commits into one rather than multiple
commits.
> whatsoever. I usually have more time to contribute on the weekends, so if
> I'll get some feedback soon, I will hopefully be able to implement whatever
> changes necessary on the weekend. If not, then another week goes by.
>
> Anyway, I really am not complaining here. Just providing a perspective from
> "the other side".
>
> All the best, and keep up the good work!
I appreciate the perspective and hope to hear more from new
contributors :) Thanks again!
> Igal
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by "Igal @ Lucee.org" <ig...@lucee.org>.
Hi all,
On 5/31/2017 1:12 AM, Mark Thomas wrote:
> On 31/05/17 04:07, Coty Sutherland wrote:
>> I've been thinking about things that we could do for Tomcat to help
>> bring in new contributors and to be more appealing to new developers.
> https://helpwanted.apache.org/
I would like to offer the perspective of the "new contributor" here. I,
for one, would love to contribute and be more involved with the Tomcat
project, and I believe that thanks to Tomcat's popularity there are many
out there just like me.
As a new contributor, the most important thing is to get some feedback.
The "worst" thing from a new contributor's perspective is that he/she
will put much time into work that will never be looked at, and all that
time will go to waste.
We understand that not all contributions will be accepted, and that they
must adhere to the standards set by the project. We also realize that
this is open source, and that the people who review the submission are
usually volunteers who do the best they can in the time that they can
afford to contribute to the project.
We still need, however, to get some feedback on our submitted work in a
timely manner before we can try again, or submit some other work.
Take for example the PRs on Github (sorry, but SVN feels like the 1980s
-- great time for partying, not so much for writing code -- and I know,
ironically the SVN project started in 2000, but I digress):
https://github.com/apache/tomcat/pulls
Anyway, there are PRs there from a few months ago, all the way to a
couple of years ago. The really old ones should be closed IMO, and
suggest to the contributors to submit again if the issue(s) are still
valid. The newer ones should be evaluated and feedback should be given
to the contributors You already "found" new contributors -- better
spend some time "cultivating" them than look for new ones who might end
up stuck in that same situation.
The most recent PR ATM -- https://github.com/apache/tomcat/pull/56 -- is
from me, and it's only been a few days, so normally I wouldn't have said
anything at this point because it hasn't been "long enough" since I
submitted it. But then I saw this email and it made perfect sense for
me to chime in.
It was very important for me to keep my PR as small and simple as
possible, so that it's easy to review and accept or reject. But there
is no feedback whatsoever. I usually have more time to contribute on
the weekends, so if I'll get some feedback soon, I will hopefully be
able to implement whatever changes necessary on the weekend. If not,
then another week goes by.
Anyway, I really am not complaining here. Just providing a perspective
from "the other side".
All the best, and keep up the good work!
Igal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Things that we can do to increase contributor involvement?
Posted by Mark Thomas <ma...@apache.org>.
On 31/05/17 04:07, Coty Sutherland wrote:
> Hi all,
>
> I've been thinking about things that we could do for Tomcat to help
> bring in new contributors and to be more appealing to new developers.
> Right now we have http://tomcat.apache.org/getinvolved.html which has
> a few bullet points and links to documentation, which is a bit verbose,
> about how to contribute to an Apache project. We also have the wiki
> (https://wiki.apache.org/tomcat/FrontPage), which mentions nothing
> about contributing. Bugzilla is a bit daunting for newcomers (thought
> we did create the "Beginners" tag to help identify some BZs for new
> folks to work on) too. I've been looking around for some ideas on how to
> make it easier for new people to contribute after having some
> conversations with friends about contributing to Tomcat and found some
> interesting examples other projects are using to help bring new people
> in, such as https://wiki.gnome.org/Newcomers (which is my favorite)
> and https://fedoraproject.org/wiki/Join. Obviously Tomcat isn't as
> large of a project as those, but it does have multiple places for
> people to contribute (Documentation, Patches, FAQ, wiki, etc) which
> could use different skill sets. This site
> http://whatcanidoforfedora.org/en would be really cool to implement,
> but at the ASF level I think (Tomcat isn't complex enough to warrant
> that, is it?).
https://helpwanted.apache.org/
> Anyway, the point of this email is really just to say that we should
> take some cues from other projects and try and develop a solid entry
> ramp to help entice new developers :) What does everyone else think?
Got for it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org