[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    How does JFX work get prioritised?
From:       phidias51 () gmail ! com (Mark Fortner)
Date:       2012-10-31 15:00:31
Message-ID: CAOwy01se93kXybVZPAgh9CPq4v2P_EkHDhUDKVaGRwK3XzL_Jg () mail ! gmail ! com
[Download RAW message or body]

As I recall, the JCP was created to solve just these types of community
engagement problems.  Anyone can join the JSR's expert panel so you end up
with input from individual contributors and corporations.  I think when I
brought that up earlier, Richard said that at some point (perhaps after
Java 8) JavaFX will have its own JSR.

If you want story point support there's a plugin for JIRA called
Greenhopper (http://www.atlassian.com/software/greenhopper/overview) that
does the trick.  But from what I've seen so far, the Oracle SDLC is not
agile, and not likely to become moreso any time soon.

The whole "squeaky wheel" approach is really unworkable for a number of
reasons:

   - Lack of transparency (both for the community and for the development
   team)
   - If Nicolas (or anyone else who's made promises) gets run over by a
   bus, then all of his promises go with him.

Depending on the culture of open source projects, one of the approaches
that HAS worked in the past involves commitment from both ends of the
equation.  The person reporting the bug or feature request provides a patch
that fixes the problem and a unit test that demonstrates the problem and
demonstrates the fix.  Those kinds of issues get a higher priority because
they are usually quicker to fix.  In this particular case, SQE could give
feedback to the person providing the patch and unit test, in case there's
some corner case that didn't get coverage.  The person providing the patch
and SQE would run the entire test suite to make sure that no regressions
were introduced.  If everything looks ok, the patch and unit test are
committed, and you see the result in the nightly build.

In terms of default priorities:

   - I would hope that any bug that casts doubt on the future viability of
   desktop java (like crashes, security issues and webstart issues) gets the
   highest priority.
   - Any issue where the the component doesn't meet the minimum standard
   set by Swing should also be prioritized high (since this would determine
   whether Swing developers bother switching in the first place).  If you want
   Swing developers to switch, you've got to exceed the capabilities of Swing
   without adding to the workload.
   - Any issue that effects the ease of development (i.e.
   creating/building/deploying JavaFX projects) should get a similar priority
   since it too would determine the likelihood of enterprise developers
   switching to JavaFX.
   - Any nice to have features (like 3D support) would get a lower priority.

But that's just my two cents worth.

Cheers,

Mark




On Wed, Oct 31, 2012 at 5:31 AM, Daniel Zwolenski <zonski at gmail.com> wrote:

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

[prev in list] [next in list] [prev in thread] [next in thread]