Re: Plugin site overhaul?

> On 14.06.2016, at 22:02, Gus Reiber 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 >

Re: Plugin site overhaul?

> On 18.06.2016, at 13:01, Tomas Bjerre 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_source=footer > Its

Re: Plugin site overhaul?

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_source=footer I also noticed it when I tried to get git-releasenotes-plugin published:

Re: Plugin site overhaul?

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. On Sat, Jun 18, 2016,

Re: Plugin site overhaul?

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

Re: Plugin site overhaul?

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. On Fri, Jun 17, 2016, 04:51 Baptiste Mathus wrote: > Thinking about it again, I somehow agree for the reasons

Re: Plugin site overhaul?

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

Re: Plugin site overhaul?

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... 2016-06-17 9:52 GMT+00:00 Adrien

Re: Plugin site overhaul?

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

Re: Plugin site overhaul?

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

Re: Plugin site overhaul?

Looks cool Gus. On Wednesday, June 15, 2016 at 5:43:22 AM UTC+9, Gus Reiber wrote: > > +1 to GitHub readme as well. Why put the same doc in 2 places. > > > > On Tuesday, June 14, 2016 at 1:30:24 PM UTC-7, slide wrote: >> >> +1 for the effort, ideally I'd like to see something that can pull >>

Re: Plugin site overhaul?

+1 to GitHub readme as well. Why put the same doc in 2 places. On Tuesday, June 14, 2016 at 1:30:24 PM UTC-7, slide wrote: > > +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

Re: Plugin site overhaul?

+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