jsr348
  1. jsr348
  2. JSR348-62

Add an additional vote type to section 6 called "Conditional Yes"

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Component/s: General
    • Labels:
      None

      Description

      (This issue is raised by me on behalf of Red Hat).

      In the JSR Review and Public Review ballots, an EC member will often cast a vote of "Yes" with a conditional clause in the comments section. There should be a formal process for addressing these conditions, perhaps tracked in the same manner as a specification issue.

      One proposal is to introduce a "Conditional Yes" option on the ballots. This means the voting EC member agrees with the JSR in principal, but has one or more issues that the voting member would like to see addressed before the next vote. The comment would be converted to a spec issue and would require that it be handled like any other issue (rejection is a possible resolution, provided there is a reason given).

      If the issue is not addressed to the voting member's satisfaction, that may translate in a "No" vote. The important part is that the reason for the change is traceable.

      This proposed process gives the public a more open view of what the EC views as problems in the spec, or how it relates to other specifications.

      The current scrolling text box that is used to display comments is very difficult to read. We would like to propose that each comment is separated into individual blockquote elements, each with a header that includes the name of the voting member. Ideally, those headings would be referencable (with anchor tags).

      Additionally, a public Item Exception section in the ballot results page would prevent issues from being forgotten. The new vote type allows for an expression of issues, yet would still allow the vote to be counted as a "Yes" vote toward moving the JSR forward. It's a more formalized way of what's currently being done (either abstaining or voting no and leaving a comment).

      This request extends the motivation of the Item Exception Ballot for a Maintenance Review to to JSR Review and Public Review Ballot.

        Activity

        Hide
        pcurran added a comment - - edited

        Hmmm...

        This is really three separate issues in one. Please separate them. (On second thoughts, no need to log an issue about the way in which the votes are displayed on jcp.org - this is way out of scope for the Process Document, being simply an implementation detail.)

        As for your first suggestion, I've already created a similar issue (prompted by comments on the Experts alias from Scott Stark of RedHat)- see http://java.net/jira/browse/JSR348-61 - in which I suggest that issues should be logged when someone votes no with comments.

        Now that I think about it, we should generalize the language to suggest that "yes with comments" (which already is permitted and even encouraged) should also be accompanied by filing one or more issues.

        I'll generalize that issue to cover both cases.

        Thanks for the suggestion.

        Show
        pcurran added a comment - - edited Hmmm... This is really three separate issues in one. Please separate them. (On second thoughts, no need to log an issue about the way in which the votes are displayed on jcp.org - this is way out of scope for the Process Document, being simply an implementation detail.) As for your first suggestion, I've already created a similar issue (prompted by comments on the Experts alias from Scott Stark of RedHat)- see http://java.net/jira/browse/JSR348-61 - in which I suggest that issues should be logged when someone votes no with comments. Now that I think about it, we should generalize the language to suggest that "yes with comments" (which already is permitted and even encouraged) should also be accompanied by filing one or more issues. I'll generalize that issue to cover both cases. Thanks for the suggestion.
        Hide
        mojavelinux added a comment -

        Great. Thanks for following up.

        Regarding the display of the comments on the jcp.org, while it may seem like an implementation detail, it's a pretty serious issue. The current layout favors the comments of a limited set of voters' comments that are visible, while other comments are hidden below the scroll.

        To make this point fit in the process document, I suggest that it be clear that "comments should have equal visibility on the ballot page".

        The current layout can be perceived by some as an intention to downplay the comments by making them easy to miss (even though I trust that in reality it was an inadvertent outcome). (Please note that is not an accusation, it's a suggested improvement to avoid such conclusions being made).

        Show
        mojavelinux added a comment - Great. Thanks for following up. Regarding the display of the comments on the jcp.org, while it may seem like an implementation detail, it's a pretty serious issue. The current layout favors the comments of a limited set of voters' comments that are visible, while other comments are hidden below the scroll. To make this point fit in the process document, I suggest that it be clear that "comments should have equal visibility on the ballot page". The current layout can be perceived by some as an intention to downplay the comments by making them easy to miss (even though I trust that in reality it was an inadvertent outcome). (Please note that is not an accusation, it's a suggested improvement to avoid such conclusions being made).
        Hide
        pcurran added a comment -

        The scrolling list may not be pretty, and it's certainly not state of the art, but I think you're exaggerating the significance. If people can't be bothered to scroll down to view all the comments then I'm afraid I don't have a lot of sympathy for them. (Would you similarly require that a JSR proposal be no longer than can fit in a web-browser without requiring the user to scroll down, on the grounds that material "below the fold" would therefore be discriminated against?)

        Be that as it may, our lone web-engineer is so overloaded with more critical matters that this is unlikely to get attention in the forseeable future. I will log it as an internal enhancement request, but I still maintain that it's out of scope for the Process Document no matter how you word the request.

        Sorry...

        Show
        pcurran added a comment - The scrolling list may not be pretty, and it's certainly not state of the art, but I think you're exaggerating the significance. If people can't be bothered to scroll down to view all the comments then I'm afraid I don't have a lot of sympathy for them. (Would you similarly require that a JSR proposal be no longer than can fit in a web-browser without requiring the user to scroll down, on the grounds that material "below the fold" would therefore be discriminated against?) Be that as it may, our lone web-engineer is so overloaded with more critical matters that this is unlikely to get attention in the forseeable future. I will log it as an internal enhancement request, but I still maintain that it's out of scope for the Process Document no matter how you word the request. Sorry...
        Hide
        pcurran added a comment -

        I'm closing this issue since the essence of the original suggestion (to tie comments on votes to issues) has been addressed in http://java.net/jira/browse/JSR348-61.

        There was further discussion on the alias about the specific suggestion to formally define "conditional yes" and "conditional no" votes. For the record, here's what Scott Stark suggested:

        We should define the notion of conditional yes/no votes you introduce in the first part of the message along the lines of:

        Conditional Yes Vote, a yes vote in a ballot that references one or more Issues that must be resolved in order for the yes vote to be awarded in the next phase of balloting.

        Conditional No Vote, a no vote in a ballot that references one or more Issues that must be resolved in order for the vote to be changed to a yes vote in the next phase of balloting.

        I responded to this by saying:

        There's value in mentioning the concepts but there would be no need to formally define them unless we need to use the terms again. We might be able to achieve the same effect more economically by having an Issue state of "critical" or "showstopper" or whatever.

        Considering the discussion at this morning's Working Group meeting, and the resolution of http://java.net/jira/browse/JSR348-61 it doesn't seem as if formal definitions will be necessary. We can repopen this issue if necessary.

        Show
        pcurran added a comment - I'm closing this issue since the essence of the original suggestion (to tie comments on votes to issues) has been addressed in http://java.net/jira/browse/JSR348-61 . There was further discussion on the alias about the specific suggestion to formally define "conditional yes" and "conditional no" votes. For the record, here's what Scott Stark suggested: We should define the notion of conditional yes/no votes you introduce in the first part of the message along the lines of: Conditional Yes Vote, a yes vote in a ballot that references one or more Issues that must be resolved in order for the yes vote to be awarded in the next phase of balloting. Conditional No Vote, a no vote in a ballot that references one or more Issues that must be resolved in order for the vote to be changed to a yes vote in the next phase of balloting. I responded to this by saying: There's value in mentioning the concepts but there would be no need to formally define them unless we need to use the terms again. We might be able to achieve the same effect more economically by having an Issue state of "critical" or "showstopper" or whatever. Considering the discussion at this morning's Working Group meeting, and the resolution of http://java.net/jira/browse/JSR348-61 it doesn't seem as if formal definitions will be necessary. We can repopen this issue if necessary.

          People

          • Assignee:
            Unassigned
            Reporter:
            mojavelinux
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: