How does JFX work get prioritised?

[Daniel Zwolenski]

Thanks for the reply - believe it or not it does help to know this. At
least the process is just loose rather than deliberately biased towards
commercial customers, etc.

I don't think you're going to be surprised when I say that this process
doesn't look quite ideal. It's quite a closed process and an unpredictable
one. From a community perspective there's no real visibility on what
priorities are, how much 'weight' something has or why, and when our fixes
will go in if we provide them. That doesn't really foster contributions, or
even voting or bug raising. At the same time it can lead to resentment as
to "why didn't my bug get fixed!".

>From your team's perspective you've pretty much told us that the best way
to get something we want in is to spam all your private inboxes and annoy
the hell out of everyone and get all our friends to do the same - squeaky
wheel policy. I reckon I'm pretty annoying at times and it hasn't paid off
yet, I don't think anyone wants to encourage me to be more vocal!

I guess it all depends on whether you are happy with this process? If so,
then business as usual and at least we now have some insight into the
process. If not we as a community then would it be worth throwing it open
to the community for ways to improve this process? Perhaps other people
have experiences on similar open source projects and can suggest systems
that work well (or highlight ones that don't)?

I've never been involved with a community process like this but I have
worked on a number of JIRA-based projects with clients driving the priority
list. For me some of the things that worked would seem to be a good idea
for JFX.

For example, I'd really love to see the 'Roadmap' gadget working in JFX
JIRA (currently it shows as empty), We'd then be able to very easily see
the upcoming releases and what features are planned when (or maybe you have
another way of showing this - your JIRA setup is a bit weird to me?).
Visibility on this would allow community members, your team and your
commercial clients to see all the bugs and all the issues ahead of our
issue which could well lead to us saying things like "ok, well some of
those things really are more important than my issue", or "ok that'll be
here mid next year, I can do a work around until then".

Another great tool is the voting mechanism. I've tried to push for this
before and there was some interest but it never really eventuated. If
*everything* could be prioritised on a defined point scoring system (i.e.
move away from private emails and get these people to vote) then there
really couldn't be much complaining from any party. If commercial users and
Oracle employees need to have more weight than us plebs then I could live
with that - we just need to weight votes, so a vote by a JFX developer or
Oracle gold client is worth 10 points, and a vote by us plebs is worth 1
(or whatever). I know JIRA doesn't support weighted votes out of the box
but if you were genuinely interested in doing something like this I would
consider trying to write a plugin for it.

And then story points have always been my favourite tool for this sort of
stuff. If every issue was given a story point ranking then you can say we
will aim to get X story points done in this release. If you want to define
a ratio say 2/3 have to be bug fix and 1/3 can be new features then that
works well for making sure the rate of bug fix is higher than the rate of
bug creation. The great thing about story points combined with a roadmap is
that if my feature is behind a bunch of bugs well then if I help you guys
resolve those boring bugs my feature might make it on the list. In fact
that would be your easy comeback whenever someone complains their bug is
not being fixed: "help us sort out these bugs and yours is next on the
list". Even I'd have no comeback to that.

Basically all things just aimed at predictability and visibility. Maybe
there are better ways to achieve those than my suggestions, but I do think
achieving them is fairly important to a happy, healthy community that
actively contributes and feels warm and fuzzy about doing so.

And imagine, if you had a defined process like this, you wouldn't have to
put up with me trying to be the loudest squeaky wheel all the time. No more
emails like this one. Surely that alone would be worth it!


On Wed, Oct 31, 2012 at 2:40 AM, Richard Bair <richard.bair at oracle.com>wrote:

> 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?
> >>
> >>
>
>