danno.ferrin at shemnon.com
Tue Jan 22 12:16:10 PST 2013
These requests are more meta to the process than the platform itself
1) A list of desired patches/work. Maybe a tag in Jira 'patches-welcome'
as well. Rather than deciding what the potential contributor thinks is
valuable this list would help them prioritize contributions that are more
likely to be accepted.
2) The lifecycle of a patch/bug report. What parts are gating, where it
might get stalled, when to shake the tree, what to expect. Right now I
have two issues with patches that have been sitting for some time
and RT-26719 <http://javafx-jira.kenai.com/browse/RT-26719>, which I
consider a straight up bug). I don't know if it is a time issue with the
engineer, if they didn't like my patches, or if they have been rejected. A
prompt response that either adds the patch to the review queue for
commitment or bounces it back to the developer is what I see as lacking. A
prompt rejection is better than neglect.
On Tue, Jan 22, 2013 at 12:56 PM, Richard Bair <richard.bair at oracle.com>wrote:
> I want to write a bunch of documentation on our wiki around working with
> and contributing to openjfx. Some of this will be on-boarding documentation
> (including building, testing, etc). Some of it will be architecture. Some
> of it will be features.
> What are the things you'd like documented on there? What would have been
> (or would still be) most useful in understanding the platform when
> approaching it from the perspective of a contributor (whether contributing
> patches or bug reports etc)?
There is nothing that will hold me back. I know who I am....
I remember wher I came from, and I feel stronger for knowing.
Zane, Ninja of Ice. Ninjago S01E07
More information about the openjfx-dev