How does JFX work get prioritised?

[Richard Bair]

Haha, threw me under the bus :-).

There isn't much process. We do get feedback from our inbound marketing team from both looking at competitors, market trends, and customer requests. If you have commercial work going on and haven't emailed Nicolas Lorain, you ought to do so. These requests coming from our inbound marketing / product management team are their asks for a release. The engineering team has another body of work that we'd like to do, driven by our experience as engineers with the product, things we read on blogs or in emails or on mailing lists such as this, and blind spots and holes that we just know about since we didn't have time in a previous release to do everything we wanted to our satisfaction. Those are our asks.

The high level big-picture items are negotiated between engineering and product management. Engineering gives estimates for the amount of work, etc. Product management comes with dates (which are mostly set in stone years in advance, because it is part of the JavaSE release dates, including update releases), although of course dates can be adjusted down the line. These items which will take more than 2 weeks to complete are "Features" in JIRA. Those items which are new API etc but which are less than 2 weeks work are "Tweaks". Bugs are "Bugs" (ie: something doesn't work the way it was meant to work -- these can affect API but are always of the nature that they should have worked but was coded improperly etc).

As to what goes into a release, it is a negotiation between Product Management, Engineering, and SQE (Software Quality Engineering). PM says "I want everything", Engineering says "I can give you this and this", and SQE says "I can only test this". And thus we get down to some number of Features that we can handle in a release. For Tweaks and Bugs, it is only a negotiation between Engineering and SQE. If we can write our own tests on engineering side, then SQE doesn't have to be impacted, and those tweaks / bug fixes are easier to get through.

Votes are something that we have done an awful job of taking into this process, but both engineering and PM should be taking these into account as customer requests in the planning process.

We try to reserve a significant amount of time for bug fixing. I prefer fewer features until we can get the bug backlog under control and keep the quality high. Obviously PM cares about that too to some extent, but they are really the customer advocate and asking for every new feature under the sun that their contacts have requested.

Which is why we've had a hard time between me asking for contributions, people giving contributions, and then they aren't being taken. The problem is that, my main issue is that the bug backlog *must* get under control (including performance work), and that every new feature increases the backlog and makes it that much more unlikely that we'll ever get it under control. Of course, the sorts of things people want to contribute more often than not are new features -- but that usually makes our jobs harder, not easier, because of the level of testing etc that has to go into new features, so that even if I take them on the engineering side, SQE can veto based on the amount of work they already have to do. On the other hand, the most valuable contributions at this stage in the project is also the least glamourous -- but fixes. I have a number of those, and these need to be treated as gold. This is also why I'm spending almost all of my time getting the rest of the source code open sourced and improving our build and related processes, and getting the test code all open sourced so that this can be as dead easy a process as possible. Steve, Jasper and I are shortly going to have this documented in the WIKI. I am going to get the build scripts out there today, hopefully, although they won't really work until the rest of the code is open sourced, but I want to make it so that anybody can follow along and see what we're up to.

Richard

On Oct 29, 2012, at 5:41 PM, Kevin Rushforth wrote:

> Richard Bair should answer the more general question you raised.
> 
> -- Kevin
> 
> 
> Daniel Zwolenski wrote:
>> Good to know, but I was just using this issue to frame the question: what's the process you use to determine what's in or out? When you "reconsider" this, who will be doing the reconsidering, and what will be the determining factor of whether it is in or out?
>> 
>> e.g. is each developer or sub-team free to pick their priorities or do they come from a marketing team or a high-level management crew? Maybe there's a committee that meets once a week, month, whatever? What input do the decision makers look at when deciding, are they using solid metrics from market research, surveys, community feedback, etc, or is it more of a gut-feel thing? 
>> You mention "lobbying". What form of lobbying? What priority do JIRA votes get (traditionally none) vs "private emails", OTN forum posts, or feet stamping and generally being annoying on this mailing list (that hasn't worked for me though ;) ). Does lobbying from certain users (e.g. oracle customers) or types of users (e.g. established corporates vs "I'm a developer") get more weight than others - if so what's the weighting (how many noisy plebs does it take to balance out large corporate)? 
>> Any chance we could get some insight on any of that? 
>> 
>> 
>> On Tue, Oct 30, 2012 at 11:08 AM, Kevin Rushforth <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>> 
>>    I'll take the heat for this one. I just bulk removed the "Lombard"
>>    release for all Feature JIRAs (as opposed to Tweaks) that are not
>>    part of the list of accepted features for the release, without too
>>    much thought behind it. One reason for doing this is to not leave
>>    the false impression that they are being actively worked on, so
>>    that people can either set their expectations appropriately or
>>    lobby for it being included.
>> 
>>    Based on your e-mail, the number of votes on this issue, and a
>>    couple private e-mails I received, it seems like this is something
>>    we should explicitly reconsider.
>> 
>>    -- Kevin
>> 
>> 
>>    Daniel Zwolenski wrote:
>> 
>>        Is it possible for someone from the Oracle JFX team to outline
>>        how features
>>        get prioritised for inclusion in a release?
>> 
>>        I've been frustrated at times with things I think I are
>>        important not
>>        getting done, and I think a few others have had similar
>>        experiences. Obviously all of us think our bug/feature is the most
>>        important thing, and not everything can get done and there has
>>        to be
>>        priorities. I think it would be less frustrating though if we
>>        actually knew
>>        the process that was used to prioritise issues - who decides,
>>        and what
>>        metrics are used as input?
>> 
>>        I noted today for example, that
>>        RT-10376<http://javafx-jira.kenai.com/browse/RT-10376>,
>> 
>>        which is simply to allow maximising the stage
>>        programmatically, just got
>>        bumped so its not part of Java8 and is not part of any foreseeable
>>        release. I personally don't care about this feature so much,
>>        but it does
>>        look like a pretty fundamental, basic thing for a windowing
>>        toolkit to
>>        have, so highlights the general point:
>> 
>>           - It was raised as a "critical feature" by Jasper Potts, so
>>        it doesn't
>> 
>>           seem a case of not being recognised as important within Oracle.
>>           - It was raised back in 2010 so it doesn't seem a case of
>>        it coming in
>>           too late and just not making the cut for the release.
>>           - Based on comments from Anthony Petrov it seems to be
>>        already mostly
>> 
>>           implemented and just needs to be hooked in, so I'm assuming
>>        it's not really
>>           a big resourcing issue.
>>           - It's got 28 votes from the community, placing it at #8 in
>>        the most
>> 
>>           voted list by my reckoning, so there's no lack of community
>>        interest in the
>>           issue (3D geometry support has 12 votes for example).
>> 
>>        >From my vantage point, it's difficult to see why a feature
>>        like this
>>        wouldn't have been done months ago, let alone be off the road map
>>        completely, especially when you consider some of the more
>>        obscure features
>>        on the roadmap. Confusion over something like this, for me at
>>        least,
>>        festers into a general distrust in the process, which results in
>>        frustration around other issues I do consider important (like
>>        build/deployment).
>> 
>>        Can this confusion be lessened through some better
>>        communication? Is it
>>        possible to explain how, in this case and in general, you guys
>>        prioritise
>>        JavaFX work?
>>         
>>