Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Duplicate
    • Component/s: ci-game-plugin
    • Labels:
      None
    • Environment:
      Platform: PC, OS: Windows XP
    • Similar Issues:

      Description

      first of all, I think this plugin is a great idea, but it is not clear, at least...

      first of all, I think this plugin is a great idea, but it is not clear, at least
      for me, how this plugin calculates the points. For example:

      In the score card I have this
      3 checkstyle warnings were fixed 3.0
      1 new NORMAL priority findbugs warnings were found -3.0
      2 new NORMAL priority PMD warnings were found -6.0

      and the participants (some of then are repeating 3 or 4 times, others only once)

      However, the Leader board result in the following table
      fernando
      0.0
      marcelo
      -6.0
      isaias
      -6.0
      gelson
      -18.0
      ale
      -36.0
      andrade
      -42.0

      My question is. How the above points are divided into these developers? Why one
      have -42 and other -6 from only one build where the amount of points is -3?

      It seems that each file a developer has committed is multiplied by an given
      number of points. But if he/she has only 1 new warning and he/she has committed
      10 files, he will get -10 points. what is not fair.

        Attachments

          Issue Links

            Activity

            Hide
            fbrubbo Fernando Rubbo added a comment -

            I think I've found what is causing this odd behaviour.

            I my last build I've the following in the build changes:
            aleal.dbs: 1 commit changing some files
            daniel: 1 commit changing other files
            daniel: +1 commit changing more files
            daniel: another commit change other files

            It seems that the build's points are being added up once for aleal.dbs and 3 times for daniel. I think the way this plugin was developed does not identify that there are three commits referring to only one user which nickname is daniel. For me, it sounds reasonable if it added the build's points once for aleal.dbs and also once for daniel.

            Please, let me know if I'm wrong.

            Show
            fbrubbo Fernando Rubbo added a comment - I think I've found what is causing this odd behaviour. I my last build I've the following in the build changes: aleal.dbs: 1 commit changing some files daniel: 1 commit changing other files daniel: +1 commit changing more files daniel: another commit change other files It seems that the build's points are being added up once for aleal.dbs and 3 times for daniel. I think the way this plugin was developed does not identify that there are three commits referring to only one user which nickname is daniel. For me, it sounds reasonable if it added the build's points once for aleal.dbs and also once for daniel. Please, let me know if I'm wrong.
            Hide
            km km added a comment -

            corrected category.

            Show
            km km added a comment - corrected category.
            Hide
            pemungkah pemungkah added a comment -

            It's a decent heuristic for determining amount of change per person - a new failure is assumed to more likely be from the person who made more changes. (Admittedly, it's possibly the case that a good programmer is making more changes that work, and a bad programmer is making fewer that don't, but short of adding a "player X is a bad programmer" field I don't see a good solution - and doing that is probably not at all a good idea!)

            Show
            pemungkah pemungkah added a comment - It's a decent heuristic for determining amount of change per person - a new failure is assumed to more likely be from the person who made more changes. (Admittedly, it's possibly the case that a good programmer is making more changes that work, and a bad programmer is making fewer that don't, but short of adding a "player X is a bad programmer" field I don't see a good solution - and doing that is probably not at all a good idea!)
            Hide
            kutzi kutzi added a comment -

            Was fixed in 1.15

            Show
            kutzi kutzi added a comment - Was fixed in 1.15

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: