On 08/10/15 01:52, Daniel Beck wrote:
>
> On 08.10.2015, at 01:45, Daniel Beck <m...@beckweb.net> wrote:
>
>> So from aggregating existing comments it looks to me like the following
>> seems to be at least a reasonable basis for further discussion:
>>
>> * Use a static site generator with a Git repo on GitHub as the source for
>> the site. Goal: Allow community to contribute content.
>> [Updated Confluence could also work, but would retain the problems of
>> unreviewed content, comments, and non-plain text editing.]
>> * Have actual content, like good documentation, especially for getting
>> started. This includes moving some of the wiki's content into the site.
>> * Feature the blog [and possibly the event calendar] more prominently.
>> * Do not have "comments everywhere", limit to specific sections like the
>> blog.
>> * Make it easy to contribute, possibly through having an "Edit" ("Improve
>> this page"?) link on every page, if possible.
>>
>> Comments?
>
> Based on the discussion in this and related threads, and some existing sites
> used as "inspiration" I published my own "vision" for the new site. Just like
> Gus's, this is mostly a means to move the discussion along, so if you think
> some (or all) of my ideas are terrible, tell everyone in this thread.
>
> https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+2.0+Website+vision+from+Daniel+Beck
Thanks. I agree with most of your page.
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).
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.
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 still don't quite understand what Arquillian actually *is*, but I do
agree with the idea of having a site structured like that :)
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.
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.
Similarly the guides should be structured by language/framework, e.g.
"I'm a Ruby developer": how do I build an app? How do I test an app? How
do I deploy it?
"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.
Regards,
Chris
--
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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/5616DC2D.1090303%40orr.me.uk.
For more options, visit https://groups.google.com/d/optout.
