On 08.10.2015, at 23:12, Christopher Orr <[email protected]> wrote:

> Static site generation would be great, but as Richard commented on
> INFRA-373 (and I agreed), it becomes a bit difficult to contribute to a
> site like this when testing your contribution properly requires
> installing a site generator with a learning curve (i.e. anything
> involving Ruby, in my case).

If you just contribute content (i.e. don't toy around with internals), 90+% of 
that should be doable with GitHub's preview.

Since it's static we may even be able to have the CI build generate a zip file 
you could download and extract and that's the site, similar to e.g. Javadocs. 
So no need to run the tooling yourself, just download whatever the CI build 
generates and take a look.

I'm pretty sure the vast majority of contributions by people who aren't 
"regulars" will be very simple, like adding a new blog post, a link to 
somewhere else, or improving existing documentation. And those should be 
trivial.

> Maybe I just dislike Jekyll and Ruby (even although I use it), but in
> any case, most people can manage with Markdown, and there are ways of
> previewing that without having the full static site setup.

Exactly!

> I don't know whether comments on the blogs are useful — better would be
> to direct people straight to the blog author via email, or to the
> users/dev list?
> Nobody monitors the blog comments, and so the reply rate is virtually
> zero (in the very rare case that there *are* comments).

I'm not a fan of blog comments detached from everywhere else either. I wonder 
whether we need them at all. Since we're currently using Disqus and presumably 
would continue to do that, they could always be removed if it turns out even 
better exposure of the blog doesn't result in comments. It's not like what we 
discuss and decide now must be what we're doing unchanged for the next X years 
even if parts don't work…

> Regarding downloads, I think LTS should be presented as the default
> download option, as it should be stabler for new users.  Though that
> could also apply to the current site.

WDYT of http://www.ubuntu.com/download/desktop ? Something along those lines?

Of course IMO we'd generally like to have people use the weekly releases if 
they have no particular preference, otherwise the LTS releases and their users 
would suffer from undiscovered bugs. I'm just saying we should explain the 
options better.

> Documentation for setup should definitely be clearly structured to be
> useful for various types of people, e.g. for security people, or for
> CentOS admins, or for Debian admins etc.
> …
> "Explaining the terminology" would be good, and should also come with
> some best practices, e.g. treating workspaces as ephemeral, archiving
> artifacts, using downstream jobs — there's lots of stuff that new users
> have little to no hope of discovering on their own.  I guess that would
> come under the "getting started guides" part.


Exactly.


-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/337CA9EA-663D-472E-8E44-8D383F524E7E%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to