Re: Automatic Plugin Documentation [GSOC 2016]

I have updated my template with the code that pulls the files from github . Some of the assumptions that I have made : 1. All plugin repositories have the keyword "plugin" 2. The plugins are affiliated with github.com/jenkinsci

Re: Automatic Plugin Documentation [GSOC 2016]

(replies inline) On Wed, 01 Jun 2016, Oleg Nenashev wrote: > Yes, raw HTMLs :( > > Do you have regular team meetings in this project. > I have a bunch of questions regarding the plugin documentation format (the > document is not detailed enough), and maybe a short chat is better than a > long

Re: Automatic Plugin Documentation [GSOC 2016]

I can set one up On Wed, Jun 1, 2016 at 8:20 PM, Oleg Nenashev wrote: > Yes, raw HTMLs :( > > Do you have regular team meetings in this project. > I have a bunch of questions regarding the plugin documentation format (the > document is not detailed enough), and maybe a

Re: Automatic Plugin Documentation [GSOC 2016]

Yes, raw HTMLs :( Do you have regular team meetings in this project. I have a bunch of questions regarding the plugin documentation format (the document is not detailed enough), and maybe a short chat is better than a long review-change-review cycle. BR, Oleg 2016-05-31 17:28 GMT+02:00 Baptiste

Re: Automatic Plugin Documentation [GSOC 2016]

Hi, Sorry should already have reviewed the gdoc. Will do this evening. In general, please don't hesitate to ping me e.g. on irc as a reminder to some thread or things you're expecting an answer from Tyler or me. See below for the current email. Le 31 mai 2016 12:30 PM, "Cynthia Anyango"

Re: Automatic Plugin Documentation [GSOC 2016]

@Oleg , - How would you suggest I handle the exploit injection issues plus what is RAM HTML ? :) I feel i would need some help with that @Tyler and @Baptise - How to write multi-page documents I have found pandoc.org which renders multiple files into a single file . for example

Re: Automatic Plugin Documentation [GSOC 2016]

Hi Cynthia, Thanks for sharing the document! I've added several comments. It definitely requires much more details. My main questions would be: - How to handle the embedded content? - How to secure Jenkins website from exploit injection into ASCIIDOC? (e.g. via RAM HTML) - How to

Re: Automatic Plugin Documentation [GSOC 2016]

Hello everyone , I have put up together a document containing some of the things that will go into various doc files . Please feel free to comment and put up as many suggestions as you can . https://docs.google.com/document/d/1EHX0DJ8alsctFN6POLCehowusuikmnUMeL_5jPHVURA/edit?usp=sharing

Re: Automatic Plugin Documentation [GSOC 2016]

@Baptise I have gone through more than 20 plugin repos(am still going through more) trying to come up with a standard template , I will share the google soon On Tue, May 24, 2016 at 11:00 PM, Baptiste Mathus wrote: > Hi Cynthia, > > Not sure Oleg was referring to a specific

Re: Automatic Plugin Documentation [GSOC 2016]

Hi Cynthia, Not sure Oleg was referring to a specific plugin, more he's willing to convert his plugin docs to asciidoc IIUC. If you already know markdown, then you can consider Asciidoc being quite the same, but being more /standard/ and with more features. If you want examples of actual

Re: Automatic Plugin Documentation [GSOC 2016]

Hey Oleg , Could you please refer me to a plugin that has its documentation in Asciidoc On Sunday, May 15, 2016 at 5:38:35 PM UTC+3, Oleg Nenashev wrote: > > In Jenkins.io we support both Markdown and Asciidoc. > Asciidoc is recommended, because we use it's macros features for > particular

Re: Automatic Plugin Documentation [GSOC 2016]

If we try so summarize: - Keep It Simple (so that there's a very high chance the APD project does not end being ignored by most developers because it's too much hassle to use) - Not having to release, say, a 1.3.x to fix some typo or whatever in a 1.3 version" (probably a

Re: Automatic Plugin Documentation [GSOC 2016]

I certainly agree that pulling docs from master is the wrong approach. Just like pull the code from master and just building a plugin would be wrong. On Fri, May 20, 2016 at 3:07 AM, Cynthia Anyango wrote: > But I do not want to confuse users with documentation that

Re: Automatic Plugin Documentation [GSOC 2016]

If you simply mark new features with the version number they were/will be introduced in, then users will not be confused by the appearance of a feature in documentation that they do not see in the product. In fact arguably this mode is better for users because they can see what features are

Re: Automatic Plugin Documentation [GSOC 2016]

> > But I do not want to confuse users with documentation that does not match > a released plugin. Pulling the docs from master would be a no-go for me. > The master branch may contain work in progress and I do not want to cut a > release just to keep the docs consistent or up-to-date. Pulling

Re: Automatic Plugin Documentation [GSOC 2016]

On Tue, May 17, 2016 at 3:26 PM, Robert Sandell wrote: > I don't think we should have to rely on having to make a release just to > get a fix into the documentation. > The doc generation should be just picked from the master branch during the > static generation of

Re: Automatic Plugin Documentation [GSOC 2016]

> > But I don't want to have to release a new version of my plugin just > because I updated the tutorial or tips & tricks sections. > The new feature bug is present in today's wiki usage as well. > So there could be a manual documentation publishing trigger. Then owners will be able to get the

Re: Automatic Plugin Documentation [GSOC 2016]

But I don't want to have to release a new version of my plugin just because I updated the tutorial or tips & tricks sections. The new feature bug is present in today's wiki usage as well. /B On Tue, May 17, 2016 at 5:57 PM, Cynthia Anyango wrote: > I agree with

Re: Automatic Plugin Documentation [GSOC 2016]

> > I don't think we should have to rely on having to make a release just to > get a fix into the documentation. > The doc generation should be just picked from the master branch during the > static generation of jenkins.io unless that would take too much time. > That way a pull request with a new

Re: Automatic Plugin Documentation [GSOC 2016]

I don't think we should have to rely on having to make a release just to get a fix into the documentation. The doc generation should be just picked from the master branch during the static generation of jenkins.io unless that would take too much time. That way a pull request with a new feature in

Re: Automatic Plugin Documentation [GSOC 2016]

Hey Manfred , Thanks for your feedback , We are going to prototype both asciidoc and markdown the results of the will be hosted on jenkins.io which supports both . I will prepare a plugin subsection in the Documentation section https://jenkins.io/doc/ this is where all the plugin docs will

Re: Automatic Plugin Documentation [GSOC 2016]

In terms of asciidoc (and doc in general) usage for plugins I can see a number of ways for this to work. 1. Just write the docs and rely on the rendering in github. Similar to a readme being rendered just fine github renders any asciidoc or markdown files. E.g. see

Re: Automatic Plugin Documentation [GSOC 2016]

In Jenkins.io we support both Markdown and Asciidoc. Asciidoc is recommended, because we use it's macros features for particular cases. If you need any reference plugin with documentation in Asciidoc, please let me know. I consider moving docs for several plugins to GitHub, so I can migrate one

Re: Automatic Plugin Documentation [GSOC 2016]

I am all for asciidoc first, its the better format after all ;-) On Mon, May 9, 2016 at 1:53 PM, Baptiste Mathus wrote: > +1 Manfred. > IMO, this could even be asciidoc first, and possibly some Markdown flavour > (prolly GH's) secondly. > > > 2016-05-09 21:24 GMT+02:00 Manfred

Re: Automatic Plugin Documentation [GSOC 2016]

+1 Manfred. IMO, this could even be asciidoc first, and possibly some Markdown flavour (prolly GH's) secondly. 2016-05-09 21:24 GMT+02:00 Manfred Moser : > I sure hope this will work with asciidoc as well as markdown files ;-) > > On Mon, May 9, 2016 at 10:54 AM, Cynthia

Re: Automatic Plugin Documentation [GSOC 2016]

I sure hope this will work with asciidoc as well as markdown files ;-) On Mon, May 9, 2016 at 10:54 AM, Cynthia Anyango wrote: > > Hey Martinda , > > Thanks for your feedback . > > All that you have mentioned is within the scope of my project . > > As @Daniel

Re: Automatic Plugin Documentation [GSOC 2016]

Hey Martinda , Thanks for your feedback . All that you have mentioned is within the scope of my project . As @Daniel mentioned I will be introducing various named-by-convention files that will define all that should be contained in a plugin documentation . All the plugin documentation will

Re: Automatic Plugin Documentation [GSOC 2016]

> On 07.05.2016, at 01:00, martinda wrote: > > As a plugin user, and as a very occasional contributor, what would help me > document plugins better and faster would be to know where the documentation I > put in the code ends up on the web, and where to put the

Re: Automatic Plugin Documentation [GSOC 2016]

Hello Cynthia, As a plugin user, and as a very occasional contributor, what would help me document plugins better and faster would be to know where the documentation I put in the code ends up on the web, and where to put the documentation in the code (the help*.html files). I don't know if

Automatic Plugin Documentation [GSOC 2016]

Hey everyone . My proposal for the GSOC project : *Automatic Plugin Documentation was accepted*! Thanks to everyone who helped me out . The help really came a long way to getting the project accepted . During summer , I will be working on grabbing plugin documentation from the github