|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [JIRA] (JENKINS-9598) Include the Git p... [email protected] (JIRA)
- [JIRA] (JENKINS-9598) Include the ... [email protected] (JIRA)
- [JIRA] (JENKINS-9598) Include the ... [email protected] (JIRA)
- [JIRA] (JENKINS-9598) Include the ... [email protected] (JIRA)

With regard to apgray's proposal, I'm still not seeing the need for a different mechanism for installing plugins (even just initially) than the one we already have: the Plugin Manager.
If it's too hard to figure out that you should use the Plugin Manager to install plugins, we should improve the navigation or provide hints to the user to ease that learning curve.
If it's too hard to find the plugins you want to install in the Plugin Manager we should address that, possibly by changing the categorization, introducing a rating or popularity system, or even adding an initial wizard to guide them through selection of the most common plugins.
What we shouldn't do is introduce a redundant way to install plugins which has the side-effect of eliminating/reducing the need for users to know about the Plugin Manager. If a newbie user does their initial install via the proposed questionare-based custom bundle builder, they may well think that that's just the way that plugins are managed in Jenkins. When they next need a plugin, they may go back to that wizard, and try to answer the questions in a way to get it (and likely fail, since the questionare would be way too complicated if it covered all possible plugins), thinking that the plugins available through the bundle builder are all there are.
The vibrant plugin community is one of the things that makes Jenkins great. Let's not shoot ourselves in the feet by hiding it from the users.