Quantcast

[sonar-dev] Thoughts about accepting plugins into the forge

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[sonar-dev] Thoughts about accepting plugins into the forge

Patroklos Papapetrou
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

Dinesh Bolkensteyn-2
Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

Patroklos Papapetrou
Hi Dinesh

+1000 with your solution!!! Totally agree!! 
It combines both pre-requisites : Demand and quality.  



2013/12/20 Dinesh Bolkensteyn <[hidden email]>
Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

dcruette
Hi Dinesh and Patrokols

Want about my proposal for a new Powerbuilder plugin ?

No many users but such an old environment that users are looking for up
to date quality tools like SonarQube, combined to newer languages.

Wish to hear about it

Didier

On Fri, 20 Dec 2013 14:58:23 +0200, Patroklos Papapetrou
<[hidden email]> wrote:

> Hi Dinesh
>
>  +1000 with your solution!!! Totally agree!! 
> It combines both pre-requisites : Demand and quality.  
>
> Patroklos Papapetrou
>
> Co-Author of Sonar in Action [1]
>
> http://gr.linkedin.com/in/ppapapetrou [2]
>
> http://twitter.com/ppapapetrou76 [3]  
>
> 2013/12/20 Dinesh Bolkensteyn
>
> Hi Patroklos,
>
> You raised a very interesting point, which we already raised a few
> times internally.
>
> My opinion is that a plugin must both have some demand, and be good
> from an internal quality point of view.
>
> If those 2 conditions are not met, then chances are that the plugin
> will quickly become deprecated.
>
> Here is a possible solution which I have in mind:
>
> 1) Allow everyone to send +1 vote. The meaning of such a vote is "yes
> this plugin is useful to me".
> 2) Require at least 5 +1 votes.
> 3) Require no SonarSource / Community dev to send a -1, which means
> "this plugin internal quality is horrible".
>
>  --
> Dinesh Bolkensteyn
> www.SonarSource.com [5]
> twitter.com/DBolkensteyn [6] [7]
>
> On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou  wrote:
>
> Hi guys
>
>  Although I might be considered heretic Id like to challenge the
> current process for releasing a new plugin
> ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin [9] ) 
>
> One of the key factors to accept a new plugin to the forge is to get
> three positive votes during the first voting and no negatives. This is
> somehow understandable. I assume that wed like to be sure that plugins
> quality and features meet a minimum set of requirements before theyre
> available at the plugin center under the umbrella of SonarSource. 
>
> So far so good :) The "problem" is that voting permissions have only
> SonarSource devs and community devs which again is somehow correct
> because these devs are trusted and are more-or-less about 50 guys
> (maybe less )
>
> What happens, however, in the case of a new plugin that might be very
> useful to the thousands of SonarQube users but these 50 devs cant or
> dont want to test it but still the plugin meets all the requirements?
> We have two pending (under voting) plugins (.NET Resharper and Redmine
> ) and Id like to share one more (XMPP notifier). I cant think that the
> .NET Resharper plugin is not valuable to several SonarQube users and
> it doesnt have a place to the update center. 
>
> My point is that maybe we need some tuning to the process of
> "accepting a new plugin".
> WDYT?
> Its X-Mas time so be gentle :) 
>
> Kind Regards
>
>  Patroklos Papapetrou
>
>  Co-Author of Sonar in Action [10]
>
>  http://gr.linkedin.com/in/ppapapetrou [11]
>
>  http://twitter.com/ppapapetrou76 [12]  
>
>
>
> Links:
> ------
> [1] http://affiliate.manning.com/idevaffiliate.php?id=1233_299
> [2] http://gr.linkedin.com/in/ppapapetrou
> [3] http://www.twitter.com/ppapapetrou76
> [4] mailto:[hidden email]
> [5] http://www.sonarsource.com/
> [6] http://twitter.com/DBolkensteyn
> [7] http://www.SonarSource.com
> [8] mailto:[hidden email]
> [9] http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin
> [10] http://affiliate.manning.com/idevaffiliate.php?id=1233_299
> [11] http://gr.linkedin.com/in/ppapapetrou
> [12] http://www.twitter.com/ppapapetrou76



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [sonar-dev] Thoughts about accepting plugins into the forge

John M. Wright-2
In reply to this post by Dinesh Bolkensteyn-2
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

Patroklos Papapetrou
Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [sonar-dev] Thoughts about accepting plugins into the forge

John M. Wright-2
Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

John M. Wright-2
SonarSource folks:
Any thoughts in this?  Any chance of making any changes in the short term?

I've has some feature requests come in that I'm considering for the ReSharper plugin, but want to hold off implementing them if there's still a chance it can get it into the UpdateCenter. 

Thanks
~john


On Dec 23, 2013, at 9:28 PM, "John M. Wright" <[hidden email]> wrote:

Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

Ann Campbell
Along those lines, I briefly discussed the ReSharper situation with my boss yesterday. We're eager for this integration, but reluctant to go with something that's still considered beta.

We speculated/wondered whether part of the problem here isn't that only plugin developers - i.e. Java developers - can vote. There's plenty of C# activity on the user list, but limiting the voting community to committers, while reasonable, does limit the pool of eligible voters who will be interested enough to vote on other technologies.

If a new plugin meets the quality requirements but can't find enough support among committers, then right now it's automatically relegated to the "other" page, even if it's a useful, worthwhile addition to the larger SonarQube ecosystem. :-(



---
G. Ann Campbell
Systems Architect II
Shaw Industries Inc,
201 S. Hamilton St.
Dalton Ga 30720


On Tue, Jan 7, 2014 at 8:13 AM, John M. Wright <[hidden email]> wrote:
SonarSource folks:
Any thoughts in this?  Any chance of making any changes in the short term?

I've has some feature requests come in that I'm considering for the ReSharper plugin, but want to hold off implementing them if there's still a chance it can get it into the UpdateCenter. 

Thanks
~john


On Dec 23, 2013, at 9:28 PM, "John M. Wright" <[hidden email]> wrote:

Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards




**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

John M. Wright-2
Any of the SonarSource team want to add their opinions?

Thanks
~john


On Jan 7, 2014, at 7:41 AM, "Ann Campbell" <[hidden email]> wrote:

Along those lines, I briefly discussed the ReSharper situation with my boss yesterday. We're eager for this integration, but reluctant to go with something that's still considered beta.

We speculated/wondered whether part of the problem here isn't that only plugin developers - i.e. Java developers - can vote. There's plenty of C# activity on the user list, but limiting the voting community to committers, while reasonable, does limit the pool of eligible voters who will be interested enough to vote on other technologies.

If a new plugin meets the quality requirements but can't find enough support among committers, then right now it's automatically relegated to the "other" page, even if it's a useful, worthwhile addition to the larger SonarQube ecosystem. :-(



---
G. Ann Campbell
Systems Architect II
Shaw Industries Inc,
201 S. Hamilton St.
Dalton Ga 30720


On Tue, Jan 7, 2014 at 8:13 AM, John M. Wright <[hidden email]> wrote:
SonarSource folks:
Any thoughts in this?  Any chance of making any changes in the short term?

I've has some feature requests come in that I'm considering for the ReSharper plugin, but want to hold off implementing them if there's still a chance it can get it into the UpdateCenter. 

Thanks
~john


On Dec 23, 2013, at 9:28 PM, "John M. Wright" <[hidden email]> wrote:

Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards




**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

Evgeny Mandrikov
Hi John,

According to page http://www.sonarsource.com/company/team/ Ann is a member of SonarSource team ;) And I will try to find time tomorrow (today time to go to bed) to add my opinion. Thanks for your patience.


On Fri, Jan 10, 2014 at 12:19 AM, John M. Wright <[hidden email]> wrote:
Any of the SonarSource team want to add their opinions?

Thanks
~john


On Jan 7, 2014, at 7:41 AM, "Ann Campbell" <[hidden email]> wrote:

Along those lines, I briefly discussed the ReSharper situation with my boss yesterday. We're eager for this integration, but reluctant to go with something that's still considered beta.

We speculated/wondered whether part of the problem here isn't that only plugin developers - i.e. Java developers - can vote. There's plenty of C# activity on the user list, but limiting the voting community to committers, while reasonable, does limit the pool of eligible voters who will be interested enough to vote on other technologies.

If a new plugin meets the quality requirements but can't find enough support among committers, then right now it's automatically relegated to the "other" page, even if it's a useful, worthwhile addition to the larger SonarQube ecosystem. :-(



---
G. Ann Campbell
Systems Architect II
Shaw Industries Inc,
201 S. Hamilton St.
Dalton Ga 30720


On Tue, Jan 7, 2014 at 8:13 AM, John M. Wright <[hidden email]> wrote:
SonarSource folks:
Any thoughts in this?  Any chance of making any changes in the short term?

I've has some feature requests come in that I'm considering for the ReSharper plugin, but want to hold off implementing them if there's still a chance it can get it into the UpdateCenter. 

Thanks
~john


On Dec 23, 2013, at 9:28 PM, "John M. Wright" <[hidden email]> wrote:

Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards




**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************




--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

John M. Wright-2
My apologies - I didn't catch that since Ann's signature is for Shaw Industries. 

Would love to hear your opinion as well ... Tomorrow ;-)

Thanks
~john


On Jan 9, 2014, at 5:27 PM, "Evgeny Mandrikov" <[hidden email]> wrote:

Hi John,

According to page http://www.sonarsource.com/company/team/ Ann is a member of SonarSource team ;) And I will try to find time tomorrow (today time to go to bed) to add my opinion. Thanks for your patience.


On Fri, Jan 10, 2014 at 12:19 AM, John M. Wright <[hidden email]> wrote:
Any of the SonarSource team want to add their opinions?

Thanks
~john


On Jan 7, 2014, at 7:41 AM, "Ann Campbell" <[hidden email]> wrote:

Along those lines, I briefly discussed the ReSharper situation with my boss yesterday. We're eager for this integration, but reluctant to go with something that's still considered beta.

We speculated/wondered whether part of the problem here isn't that only plugin developers - i.e. Java developers - can vote. There's plenty of C# activity on the user list, but limiting the voting community to committers, while reasonable, does limit the pool of eligible voters who will be interested enough to vote on other technologies.

If a new plugin meets the quality requirements but can't find enough support among committers, then right now it's automatically relegated to the "other" page, even if it's a useful, worthwhile addition to the larger SonarQube ecosystem. :-(



---
G. Ann Campbell
Systems Architect II
Shaw Industries Inc,
201 S. Hamilton St.
Dalton Ga 30720


On Tue, Jan 7, 2014 at 8:13 AM, John M. Wright <[hidden email]> wrote:
SonarSource folks:
Any thoughts in this?  Any chance of making any changes in the short term?

I've has some feature requests come in that I'm considering for the ReSharper plugin, but want to hold off implementing them if there's still a chance it can get it into the UpdateCenter. 

Thanks
~john


On Dec 23, 2013, at 9:28 PM, "John M. Wright" <[hidden email]> wrote:

Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards




**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************




--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [sonar-dev] Thoughts about accepting plugins into the forge

Ann Campbell
I wear two hats. :-)



---
G. Ann Campbell
Systems Architect II
Shaw Industries Inc,
201 S. Hamilton St.
Dalton Ga 30720


On Thu, Jan 9, 2014 at 6:43 PM, John M. Wright <[hidden email]> wrote:
My apologies - I didn't catch that since Ann's signature is for Shaw Industries. 

Would love to hear your opinion as well ... Tomorrow ;-)

Thanks
~john


On Jan 9, 2014, at 5:27 PM, "Evgeny Mandrikov" <[hidden email]> wrote:

Hi John,

According to page http://www.sonarsource.com/company/team/ Ann is a member of SonarSource team ;) And I will try to find time tomorrow (today time to go to bed) to add my opinion. Thanks for your patience.


On Fri, Jan 10, 2014 at 12:19 AM, John M. Wright <[hidden email]> wrote:
Any of the SonarSource team want to add their opinions?

Thanks
~john


On Jan 7, 2014, at 7:41 AM, "Ann Campbell" <[hidden email]> wrote:

Along those lines, I briefly discussed the ReSharper situation with my boss yesterday. We're eager for this integration, but reluctant to go with something that's still considered beta.

We speculated/wondered whether part of the problem here isn't that only plugin developers - i.e. Java developers - can vote. There's plenty of C# activity on the user list, but limiting the voting community to committers, while reasonable, does limit the pool of eligible voters who will be interested enough to vote on other technologies.

If a new plugin meets the quality requirements but can't find enough support among committers, then right now it's automatically relegated to the "other" page, even if it's a useful, worthwhile addition to the larger SonarQube ecosystem. :-(



---
G. Ann Campbell
Systems Architect II
Shaw Industries Inc,
201 S. Hamilton St.
Dalton Ga 30720


On Tue, Jan 7, 2014 at 8:13 AM, John M. Wright <[hidden email]> wrote:
SonarSource folks:
Any thoughts in this?  Any chance of making any changes in the short term?

I've has some feature requests come in that I'm considering for the ReSharper plugin, but want to hold off implementing them if there's still a chance it can get it into the UpdateCenter. 

Thanks
~john


On Dec 23, 2013, at 9:28 PM, "John M. Wright" <[hidden email]> wrote:

Patroklos,

You asked:
With what criteria or how will determine if the plugin has a sufficient demand? 
I should clarify: Dinesh's response stated "My opinion is that a plugin must both have some demand, and be good from an internal quality point of view."  -- to which it was then said that demand could determined by allowing anyone to vote with "yes I find this plugin useful".  My point was that this determination should probably happen much earlier in the process that during the release vote, if it happens at all.  

User demand for an as-yet-unreleased product is very difficult to gauge (just ask your nearest product manager/sales person).  In the case of my resharper plugin, I could point to http://jira.codehaus.org/browse/SONARDOTNT-348 ("Add Support for Resharper"), which has 7 votes in JIRA and was already slated for v2.2 of the sonar-dotnet plugin, as well as the popularity of ReSharper among .NET developers, etc.  However, for other plugins, this may just be "I have a hunch people will use this".

I would suggest that gating a plugin's release based on perceived demand is potentially dangerous, but if it must occur, it should be before the developer has invested a good deal of time and effort into writing the plugin -- not right before release.

Thanks
~john


Date: Mon, 23 Dec 2013 13:39:19 +0200
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge

Hi John 
My comments inline


2013/12/23 John M. Wright <[hidden email]>
Patroklos,

Thank you for bringing this up.  As the developer behind the ReSharper plugin, this has been a bit frustrating to watch, as I feel there is demand for the plugin, but I'm unable to gather the required votes to publish it to the Update Center -- which effectively kills the plugin.

While I like the proposal from Dinesh better than the current process, I'm not totally on board with the proposal. 

My thoughts:
Since it is a requirement that a third-party plugin (ie: one not developed by the SonarSource team) be an open source plugin hosted in "the forge", I would assert that the determination if there is sufficient demand for the plugins should occur when the decision to host in the forge is made.  If there is not expected to be enough demand, then there is no point in hosting the plugin.  
With what criteria or how will determine if the plugin has a sufficient demand? 

Once the code is hosted in the forge, then I would suggest the decision to release the plugin to the Update Center should be based on:
1) Does it have a minimum set of features completed to be useful to the general user base?
2) Is the plugin unstable and/or have a user experience that reflects poorly on the SonarQube product overall?
I think you're describing the current situation. Take for instance the SonarQube Android Client. Before calling the vote, the developer described the features and it was accepted in the forge. Then a vote was triggered to collect the three +1 and ensure that quality meets the SonarSource standards.+

For the first item, the plugin developer can describe the feature set (including documentation on the wiki) and provide it with the call for votes.

For the second item, however, the problem as I see it, is that most of the active members of the voting group are Java developers, so if the plugin does not apply to Java projects, there is little motivation to test and/or code review the plugin.

So, I would suggest a couple of alternatives:
1)  Extend the current procedure so that if, after a week, a call for votes has not received the required three +1 votes and has not received any -1 votes, that the voting group be opened to include the larger user community for additional +1 votes. Perhaps this also requires a total of five +1 votes instead of the three initially required.  The larger group, however, would not be able to give -1 votes (although they could give reasons for the dev group to downvote the release).
I agree, but this make the voting process a little more complicated. 

2) Or... The Update Center could be modified to include an area specifically for "beta" or "pre-release" plugins.  A plugin's initial release would be to this area, instead of to the "main" area.  Users could provide feedback on plugins (star ratings 1-5, up/down votes, etc) and a plugin can only graduate from the pre-release area to the main area once it has enough positive user feedback.  Additionally, download counts could be added to quantify demand.  This could be further applied to the "main" plugins, and a plugin could be marked for deprecation if it's user feedback score drops too low.  Obviously, this option requires product changes, which would be a much larger undertaking. It would also need to be considered how the SonarSource commercial plugins would fit into this model.
+ 1000 . Great ideas. I'd add also the number of downloads / installs / uninstalls just like the google play market :). But again this requires some involvement from the SonarSource guys. I'm volunteering to help even by contributing to the SonarQube core if needed :)

Thanks
~john


Date: Fri, 20 Dec 2013 13:54:54 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [sonar-dev] Thoughts about accepting plugins into the forge


Hi Patroklos,

You raised a very interesting point, which we already raised a few times internally.

My opinion is that a plugin must both have some demand, and be good from an internal quality point of view.

If those 2 conditions are not met, then chances are that the plugin will quickly become deprecated.

Here is a possible solution which I have in mind:

1) Allow everyone to send +1 vote. The meaning of such a vote is "yes this plugin is useful to me".
2) Require at least 5 +1 votes.
3) Require no SonarSource / Community dev to send a -1, which means "this plugin internal quality is horrible".


On Fri, Dec 20, 2013 at 1:12 PM, Patroklos Papapetrou <[hidden email]> wrote:
Hi guys

Although I might be considered heretic I'd like to challenge the current process for releasing a new plugin ( http://docs.codehaus.org/display/SONAR/Releasing+a+Plugin ) 

One of the key factors to accept a new plugin to the forge is to get three positive votes during the first voting and no negatives. This is somehow understandable. I assume that we'd like to be sure that plugins' quality and features meet a minimum set of requirements before they're available at the plugin center under the umbrella of SonarSource. 

So far so good :) The "problem" is that voting permissions have only SonarSource devs and community devs which again is somehow correct because these devs are trusted and are more-or-less about 50 guys (maybe less )

What happens, however, in the case of a new plugin that might be very useful to the thousands of SonarQube users but these 50 devs can't or don't want to test it but still the plugin meets all the requirements? We have two pending (under voting) plugins (.NET Resharper and Redmine ) and I'd like to share one more (XMPP notifier). I can't think that the .NET Resharper plugin is not valuable to several SonarQube users and it doesn't have a place to the update center. 

My point is that maybe we need some tuning to the process of "accepting a new plugin".
WDYT?
It's X-Mas time so be gentle :) 

Kind Regards




**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************




--
Best regards,
Evgeny Mandrikov aka Godin <http://godin.net.ru>
http://twitter.com/_godin_


**********************************************************
Privileged and/or confidential information may be contained in this message. If you are not the addressee indicated in this message (or are not responsible for delivery of this message to that person) , you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender by reply e-mail.
If you or your employer do not consent to Internet e-mail for messages of this kind, please advise the sender.
Shaw Industries does not provide or endorse any opinions, conclusions or other information in this message that do not relate to the official business of the company  or its subsidiaries.
**********************************************************

Loading...