Plugin site overhaul?

[Gus Reiber]

Hey all,

   So I have on and off pushed the idea that the Jenkins community could benefit greatly from an overhaul of the wiki based plugins site. As an ultimate goal, I don't see any reason we couldn't build something that approach a modern app store, like https://play.google.com/store, but for the short run, it seems like we should be able to improove upon the browsing experience of the existing list page and detail view.

Existing: 

• list: https://wiki.jenkins-ci.org/display/JENKINS/Plugins
  
• detail: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin

I think as a minimum, we ought to be able to provide a reasonable search interface and means of filtering plugins by maintainer, Jenkins core requirement, plugins labels, and installation count. Plugins should also be assigned to categories that map to Jenkins user expectations a bit better than the current list of ~30ish maintainer assigned labels do today. Ideally the user ought to be able to manage the list of all plugins by specific features of the plugin and by some suggestion of quality or currentness of the plugin.

At various points, my interest in bringing this value to the community has been great enough to assemble a couple of different prototypes and wireframes, attempting to generate interest. I have also had a chance to play with some prototypes from others all with what seems to me to be reasonable implementation paths. Attached are a few more recent sketches showing the gist of how we might handle searching and filtering as well as the plugin details.

Anyway, at the moment, the plugin site is maintained by our representatives here in the community. So it is really the will of the community that should be reflected in any efforts that are actually deployed and later maintained by our community. Thus again, I am looking for grass roots support for the effort, support that potentially includes some avenue for long term hosting and support.

So my questions are these: Is enhancing the plugin site really worth that degree of effort to the community? If you think it is, would you be willing to join the effort, both for the immediate development needs, but also for longer term support? Do you have any experience with other communities who manage to accomplish this sort of ends?

...and finally, could you help articulate a set of minimum requirements that would make overhauling the plugin site worth while?

Thanks in advance,

Gus

[Slide]

+1 for the effort, ideally I'd like to see something that can pull information from the github README.md files and have people push updates to the descriptions that would be shown to their own plugin repositories. Perhaps some of the other information could be pulled from a metadata file that was also in the plugin repository. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/33ab5051-e2b8-4684-8d9e-0d5aa6ab1284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gus Reiber]

+1 to GitHub readme as well. Why put the same doc in 2 places.

[Tom Fennelly]

Looks cool Gus.

[Robert Sandell]

No please, how many times do I have to plead my case here?

The readme in the root of the repo is IMO aimed at describing the repository you are currently looking at; e.g. what it is, how to build it, who maintains it, links to additional resources (like user docs) etc. it is not the user documentation, it is developer documentation.

You should sync with the GSoC project that is currently going on user docs: https://groups.google.com/forum/#!searchin/jenkinsci-dev/GSoC/jenkinsci-dev/kNZMOsF_ueA/15BWeTdXDQAJ

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d8062fe5-ddd3-49b7-b530-6721ffa9243d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Adrien Lecharpentier]

I agree with Robert. Moreover, Readme files across the repositories are not containing the same details, are not written the same way and some repositories don't have any. I'm all for KISS principle but I don't think README.md is the place to old this but it should be on the repository so the maintainers have full control on it and users can offer fix / enhancement on the doc through PR.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS0WLq1yfKv4FJB4JTyTwYZe8bSPZvttHFfTcxbL2HVf1w%40mail.gmail.com.

[Baptiste Mathus]

Thinking about it again, I somehow agree for the reasons above, and also probably because of legacy reasons:

If we are to use the hundreds of already existing README, there's a good chance to see a lot of inconsistencies flowing through the documentation pipe...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAKwJSvy8rmw%2B%3D%3D0rOnmE4xAB8RJk-a427eW7j-nq%2BoUutu8Xnw%40mail.gmail.com.

[Jesse Glick]

I have argued for getting rid of the “feature” of sucking in
`{excerpt}`s from the wiki for display in the update center (it is an
infrastructure headache), and I would likewise argue that a revamped
plugin list should obtain all of its metadata from the same source the
update center does, which should be plugin `*.hpi` files exclusively.
In other words, it does not matter where you host the plugin or how
you build it, so long as you conform to a documented file format and
publish to the specified artifact repository.

Now metadata could include _links_ to additional information (user
guides, etc.) which could live anywhere. Changelogs demand special
consideration, though: it is long-form content which really needs to
be in a machine-readable format so it can be displayed in different
modes. For example, if you are looking at the _Updates_ screen inside
Jenkins, you could click an expand button next to a plugin and see a
list of changes since the installed version.

[Slide]

I never said the current readme file would be used, just something that is in the repo. It would be nice to be able to manage as much as possible from the repo.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS6V8Wp8jn0BRWX1mfR%3D4CbekFZxoCYVbOf8u-92g_jm1g%40mail.gmail.com.

[Tomas Bjerre]

Have you seen Jucies? And this issue: https://github.com/jucies/releases/issues/15 ?

I think it would be much better if competition among plugins were allowed. Many times I've lost interest in fixing a problem when I've browsed the code of plugins. Simply because there are too many bad decisions made, to much ugly code to fix... and it feels that the solutions should be to just rework the whole implementation. But if I would do that, I would not get the new implementation published anywhere. So I don't, and the code quality remains in a crappy state.

[Slide]

Why would you not get the solution published anywhere? While we do encourage people to fix issues in existing plugins or add features to existing plugins, we don't keep people from contributing. I'm saying this as a member of the hosting team that reviews plugin submissions.

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/72056174-8325-4e19-8a58-7afd15fc5c1d%40googlegroups.com.

[Tomas Bjerre]

I first noticed the problem when I tried to fix violations-plugin:

https://groups.google.com/d/msgid/jenkinsci-dev/ba38fabe-ff19-4828-a737-d2320ea5681f%40googlegroups.com?utm_medium=email&utm_source=footer

I also noticed it when I tried to get git-releasenotes-plugin published:
https://groups.google.com/d/msgid/jenkinsci-dev/06fbe64c-c228-47da-a5cd-b8d070dc16a0%40googlegroups.com?utm_medium=email&utm_source=footer
Its now merged into git-changelog-plugin and is causing confusion among users who install the plugin and get 2 similar post build steps.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/2nqWoE1FfOo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdYji0F6FPwYL66HD4eFPPv8aQ3K71nWHU7d0iPXL5rTQ%40mail.gmail.com.

[Daniel Beck]

> On 18.06.2016, at 13:01, Tomas Bjerre <tomas.b...@gmail.com> wrote:
>
> I also noticed it when I tried to get git-releasenotes-plugin published:
> https://groups.google.com/d/msgid/jenkinsci-dev/06fbe64c-c228-47da-a5cd-b8d070dc16a0%40googlegroups.com?utm_medium=email&utm_source=footer
> Its now merged into git-changelog-plugin and is causing confusion among users who install the plugin and get 2 similar post build steps.

I'm sorry that your hosting request experience was so bad. At no point was your request denied. That thread looks to me like you took us up on the suggestion. In fact, my message in that thread only makes sense if your plugin is still on track to be hosted, but a day and two messages from you later you posted the PR, effectively (at least as far as I understood it at the time) revoking the hosting request.

In addition to not refusing to host your plugin, we did not ask for a 'merge' of two plugins in the form of just copying the sources of one over to the other. AFAICT this could easily have been one post build step with a mode switch of some sort, or whatever makes sense for the related functionality in these two plugins.

Regarding the earlier week long delay -- hosting request emails getting ignored or getting no response for weeks is the reason we moved to JIRA for these half a year ago, so this doesn't happen anymore. As it's still all volunteers (and only a few as well), there are delays of a few days here and there, but overall hosting requests are now handled more quickly.

[Daniel Beck]

> On 14.06.2016, at 22:02, Gus Reiber <gre...@cloudbees.com> wrote:
>
> So I have on and off pushed the idea that the Jenkins community could benefit greatly from an overhaul of the wiki based plugins site. As an ultimate goal, I don't see any reason we couldn't build something that approach a modern app store, like https://play.google.com/store, but for the short run, it seems like we should be able to improove upon the browsing experience of the existing list page and detail view.
>

As this thread appears to have been veered off into (mostly) unrelated topics, I am restarting the plugins site discussion here:
https://groups.google.com/d/msg/jenkinsci-dev/a8rqIYaoEWA/TtkKBNaIBgAJ

I'd appreciate if the plugins index related discussion would continue there.