[2.0] Website rebump

[Kohsuke Kawaguchi]

I'm pulling out the website change part of the Jenkins 2.0 proposal from the mega thread here to go a bit deeper on it.

I talked to Gus Reiber, who is the only web design guy that I know of in this community, to walk me through how one goes about the website project like this. Based on that, I started capturing high-level tasks in here.

And I'm going to explain it here as well.

First, one should think in terms of data we want to present in a website organized in "information schema", which I mentally translated to Node Type in our current Drupal. For example, a blog post is a schema, which consists of title, author, date, content in markdown, tags, .... There's also a mailing list, which has subscribe/unsubscribe/archive links and the name.

So one of the important efforts is to build that schema (INFRA-374), and eventually the actual contents that follow the schema. 

Then there's a separate tech effort. In the original proposal, I've written that we should move away from Drupal and into a static site generator. This feeling was also shared by Tyler and Daniel (aka the infra team.)

 

The goal here is to improve the community participation into the content by lowering that bar, and also secondarily reduce the infra overhead. We think the static site generator backed by a Git repo in the jenkinsci org achieves these goals.

So there's a need for some preliminary work to prove out these goals, as well as making sure tha it adequatel supports content/presentation separation. It could be perhaps as easy as dusting off Tyler's earlier Jekyll conversion effort, or maybe it could be forking off an existing website for another project and modifying it. So that's INFRA-373.

Then we need to find someone who can design the presentation layer. Write HTML/JavaScript/CSS as templates for those static site generators (or a Drupal theme if we are going to continue with Drupal.) That's INFRA-372. And ideally this person helps us through the above two tasks as well. I can't think of anyone in the community who has bandwidth to do so, so CloudBees is willing to fund this role. If anyone capable is willing, please let us know.

Then there's more isolated but just as important story of the domain name. Nicolas said in the mega thread that we should approach the owner of jenkins.org. So I captured that as INFRA-371. I'm still proposing http://jenkins.cd/ which we have already acquired just in case, and I expect some heated discussions on this topic. After all, naming is one of the only two hard problems in computer science.

So that's how I'm seeing this project so far. Tyler suggested in IRC that we should start building this out in Wiki pages and he created this, whicch we need to fill in.

Any thoughts, feedbacks etc are welcome.

--

Kohsuke Kawaguchi

[R. Tyler Croy]

(replies inline)

On Tue, 29 Sep 2015, Kohsuke Kawaguchi wrote:

> I'm pulling out the website change part of the Jenkins 2.0 proposal from the
> mega thread

> <https://groups.google.com/forum/#!topic/jenkinsci-dev/vbXK7JJekFw> here to

> go a bit deeper on it.

Reiterating the link that KK included at the bottom of his email:

<https://wiki.jenkins-ci.org/display/JENKINS/Website>

It's a bit bare, but I'll fill in more over the next week or two :)

From my perspective, as one of the early folks who spent far more time than is
appropriate dealing with jenkins-ci.org, I'm most interested in getting more
plugin developers contributing website/blog content.

I think Twitter and jenkins-ci.org are prime locations to communicate the
problems that developers are solving and how they're solving them to the
broader Jenkins user community.

While I think the wiki is a great, easy to edit, place for the "current plugin
doc" but content to introduce "here's this common problem JS developers have,
and here are some good plugins to solve it" is something not well done right
now. And it's something that I think the plugin devs are in a good position to
provide. *Histoically* this hasn't happened, I believe, because contributing to
the site is an opaque and not-well-understood proposition.

If this sounds compelling to you, please add what would help you contribute
content to this page:
<https://wiki.jenkins-ci.org/display/JENKINS/Revamped+jenkins-ci.org+requirements>

> I talked to Gus Reiber, who is the only web design guy that I know of in
> this community, to walk me through how one goes about the website project
> like this. Based on that, I started capturing high-level tasks in here

> <https://issues.jenkins-ci.org/browse/INFRA-370>.

> <https://wiki.jenkins-ci.org/display/JENKINS/Website>, whicch we need to

> fill in.
>
> Any thoughts, feedbacks etc are welcome.
>
> --
> Kohsuke Kawaguchi
>

> --
> 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/CAN4CQ4xirdymZTs9X5E0VKay8TUx1XLSRwGce5JBFsvhPXDV7Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------

[Richard Bywater]

Wasn't sure exactly where discussion on the individual issues should go so I stuck a comment in the website issue. If it was better to stick it on the mailing list or wiki then please let me know.

Cheers
Richard

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20150930023726.GG2353%40blackberry.coupleofllamas.com.

[Kohsuke Kawaguchi]

Someone pointed me a Reddit thread about Jenkins 2.0, in which one guy compares what he values in Bamboo.

These would be great additions to our feature listing page in the website. Let's capture this somewhere.

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

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

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

For now, I think it's good to keep the discussion in ML because there are enough people participating in 2.0 conversations in real time. We can then summarize our consensus into tickets.

So I'm going to respond you here.

In INFRA-373, you wrote:

Depending on what the scope of the website is (e.g. is it just replacing what is in Drupal, or replacing Drupal + all of Confluence, or Drupal + some of Confluence) I think, if the goal is to lower the bar, things like the Arquillian example in my opinion wouldn't meet that goal and, in fact, possibly raise the bar.

So the scope does stop short of replacing Wiki. I just want the new tech infra to be able to eventually replace Confluence.

 

As far as I can tell, and please tell me if I'm wrong, to do a change to a page you would need fork the Git repo, find the file that matches the content you are wanting to change, change the file, then create a PR for the change. If you wanted to actually make sure it looked like the correct sort of change you'd need to install Ruby and associated GEMs to be able to check your change? This would also imply that people would have to have a GitHub account presumably.

If this is the flow it is indeed harder than Confluence, but I think we can do a lot better. The flow that I think we can do is:

1. User clicks an "Edit" button on the page
2. S/he lands on GitHub editor page
3. S/he edits Markdown (or asciidoc or some such) and uses the preview button to see the change
4. S/he clicks the only big green button on the page and that creates PR.

 

Right now in the Confluence style approach, you would just hit Edit, use the WYSIWYG editor to make the change, and then hit Save. Access is via a multi-purpose LDAP account.
To me the latter seems a lower bar than the former?

I'd like to think that the above flow is comparable. And for people like us who edit stuff a lot, static site is much easier to deal with --- no captcha, much faster editing, staging changes beforehand, reviewing change with others, etc.

2015-09-30 0:03 GMT-07:00 Richard Bywater <ric...@byh2o.com>:

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

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

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

And to tie back other parts of the conversation into this thread, Gus posted his thought as a Wiki page here and it's quite a read.

My key take away is that we can drive participation more by encouraging people to sign up and create an account, which converts them from anonymous drive-by visitors into a "card carrying member of the Jenkins community", which makes a lot of sense.

And I see a start of the content schema definition in there as well.

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

And this is the earlier prototype done by Tyler.

--

Kohsuke Kawaguchi

[Daniel Beck]

On 02.10.2015, at 20:17, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

> My key take away is that we can drive participation more by encouraging people to sign up and create an account, which converts them from anonymous drive-by visitors into a "card carrying member of the Jenkins community", which makes a lot of sense.

It's definitely in interesting concept.

The major problem I see with this is the need for moderation when everyone is allowed to post everywhere. And that doesn't even consider the manual work needed to correlate the work of numerous individual contributors as mentioned at the bottom. This requires that the moderator tools are exceptionally strong to not take up a lot of time.

One other issue that concerns me is that the vision requires a lot of participation to take off. Maybe I'm too pessimistic here, but I see a similar situation like those small business web sites with a section called 'special offers' or 'news' that is never updated. It just looks sad if e.g. you can vote on things in a list, and nothing has been voted on. A site should grow towards the described level of participation rather than go from basically nothing to that level. What do others think?

[Gus Reiber]

That's fair. 

Moderating a sight can get to be a lot of work.

...although, at the point at which you have so much externally contributed content that the task of moderating the site becomes a big burden, the site is almost by definition a big success. The current website doesn't generate a lot of comments or article contribution so this problem doesn't exist. The bigger problem of not so great website exists, instead.

The way I see it is this... to be a good site, the site needs to have a lot of fresh and quality content. If you write all that content yourself, you have a lot of work to do all the time, because the content always needs to be updating. If your visitors write some of that content for you, you have somewhat less work, but you also have somewhat different work. But again, what makes the site good is quantity of material (and quality, but quality comes from quantity).

We don't get site traffic until the site is good.

...so step 1 is write a lot of good content.

...step 2 is let other people augment that content.

...repeat and edit as necessary.

[jieryn]

Seriously, this idea is so obvious I almost hate to mention it.

Make the site a repository and accept pull requests. How hard is that?
I bet the site would improve drastically with small and simple pull
requests, but also large changes which let users really go wild.

Jenkins was made great by Kohsuke and the community, in probably equal
measures. Let the community carry the rain water on this. Make the
site a git repo and start accepting pull requests.. This leading by
singular people is not working out at all. I'm sorry. I really
appreciate your efforts, but I consider them not good and/or
misguided.

Let's let the community decide it with pull requests.

> --
> 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/cc4e2251-3fd0-44dd-90e1-6e38d685cccb%40googlegroups.com.

[Gus Reiber]

Fair enough.

Let's see the pull requests, then. It has been a long time and they haven't come.

...10 years as you point out for the product GUI. I am not sure when the Jenkins-ci.org website was last overhauled, but I am guessing at least 5 years ago.

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/EMbE3a4u8nA/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/CAArU9iYeyxfiA-E2Lr1Pepfo1xVf1RRxtC0KKdkXvzVa3%3D7-NQ%40mail.gmail.com.

[jieryn]

Show me the beef. Where's the repo?

> https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXxpzB2A666w-vApB1AUEQ%2BxFTWaBVc9O9Ja6xpo2_P6Dg%40mail.gmail.com.

[Daniel Beck]

jieryn <jie...@gmail.com> wrote:

> Show me the beef. Where's the repo?

Right now, we don't have a Git repo or pull requests, because it's Drupal rather than a static site. The site doesn't even integrate with the common Jenkins community accounts (or GitHub) that everyone already has.

> Seriously, this idea is so obvious I almost hate to mention it.

Tyler, KK, and I all think a generated static site, backed by a public GitHub repo, is the way to go. Then we'll have the backend that enables people to send PRs for everything (not just new content pages, but improvements to the layout etc.).

IOW I think you'll be happy with where we're going if we're going in the direction we currently favor :-)

[Christopher Simons]

I use Jenkins but haven't been part of the developer community
historically, so some user/outsider perspective may be of interest. Of
course, I'm not claiming to speak for all users:

On 10/6/2015 6:17 PM, Gus Reiber wrote:
> The way I see it is this... to be a good site, the site needs to have a
> lot of fresh and quality content.

I don't think the Internet needs another site trying to generate
content, come up with "something to say." The Jenkins website is not a
news site nor a trade journal. It is a place people go to download
Jenkins or to find documentation.

> We don't get site traffic until the site is good.

Respectfully, I think this is mistaken. The way to get "traffic" is to
create a good product that people want. If people want to download
Jenkins, they aren't going to think to themselves, "Well, Jenkins is the
best open source CI server, but I'm not going to download it because
their website is ugly." The site is a means to an end, and that end is
downloading Jenkins or finding documentation.

The Jenkins site should get traffic because people want to use Jenkins.
Not because they think they might find good articles or "content"
there. We all deal with enough "information overload" already. I think
putting some documentation up about best practices is a good idea, but
the idea of the Jenkin's website pushing articles in my face, trying to
sell me on stuff, asking me to subscribe, etc. makes me want to vomit
and likely would lead to me avoid visiting the website entirely,
possibly even to looking around for a different CI tool.

[Christopher Simons]

On 10/7/2015 8:51 AM, Christopher Simons wrote:
> ...

>
> On 10/6/2015 6:17 PM, Gus Reiber wrote:
>> We don't get site traffic until the site is good.
>

> The Jenkins site should get traffic because people want to use Jenkins.

Anyway, I don't think the purpose of the Jenkins website is to get as
much traffic as possible and grow as much as possible (except in the
sense that more traffic equates with more people using Jenkins), but
rather to provide a pleasant and usable experience for people who came
to the site to download Jenkins or to find documentation.

[Daniel Beck]

On 07.10.2015, at 14:51, Christopher Simons <christophe...@gmail.com> wrote:

>> We don't get site traffic until the site is good.
>
> Respectfully, I think this is mistaken. The way to get "traffic" is to create a good product that people want. If people want to download Jenkins, they aren't going to think to themselves, "Well, Jenkins is the best open source CI server, but I'm not going to download it because their website is ugly." The site is a means to an end, and that end is downloading Jenkins or finding documentation.
>
> The Jenkins site should get traffic because people want to use Jenkins. Not because they think they might find good articles or "content" there. We all deal with enough "information overload" already. I think putting some documentation up about best practices is a good idea, but the idea of the Jenkin's website pushing articles in my face, trying to sell me on stuff, asking me to subscribe, etc. makes me want to vomit and likely would lead to me avoid visiting the website entirely, possibly even to looking around for a different CI tool.

We're not going to sell things. Well, except for Jenkins-related events like the Jenkins User Conferences, but I think those have a place on the Jenkins site. We're not going to require subscription to just consume content. There's not going to be a pay-wall, or even a subscribe-wall. If technically possible, any contributions will only require a GitHub account, or a Jenkins community account, which you already have if you've edited the wiki or filed a bug.

However, there's still a lot left to write about in more or less regular posts. Recent blog posts I've written include highlighting cool, lesser known plugins, tools related to Jenkins, and news about the Jenkins project itself. I think it would also be interesting to also link to what others write about Jenkins. Not to garner pointless comments, but to inform people about what's going on with Jenkins and give them new ideas what they can do with it.

[Slide]

Would the blog be available to anyone, or just CloudBees employees?

--
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/0F738FB9-CC91-407D-9757-01B7855FC2B9%40beckweb.net.

[Gus Reiber]

To my mind, anyone with something to say should be encouraged to blog on the site.

It should be easy for them.

And that is the sort of traffic, I think we should seek to encourage.

I like Christopher's comments quite a bit, so I think I should clarify my own position a bit. I don't think Jenkins-ci.org needs to be adding new types of content, like tech briefs or newsish content, but the content that is there now is both difficult to find and not particularly fresh.

Correct me if I am wrong, but navigating the documentation on the site is pretty rough. First, it is hard to tell you are looking at product doc vs. a blog vs. the plugin list, and more importantly, it is really hard to tell if a piece of doc is current or what version of Jenkins it was written against. For events, there is no direct tie between what shows up on the calendar and event listed in blog posts or in the office hours page.

...also, it is hard to find this mailing group and know that this is actually where the meat of the community interactions happens if you are starting from Jenkins-ci.org.

As far as traffic growth goes, I believe if a site is well assembled and managed, more visitors == better site, because those visitors contribute. It is also a good way to assess the health and size of the community. I think a big and growing community is something we all want. We don't have this problem, but communities sometimes shrink in size and participation. When that happens, it becomes a lot harder to find help and support for your own needs.

...so I stand by the statement growth is good.

And it is good for everyone.

--
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/EMbE3a4u8nA/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/CAPiUgVd1%2BwB2yd7JjA%3Dxo%3DbU6A0B5u9rMXsMHJkmiGWJ2iVvmg%40mail.gmail.com.

[Slide]

That sounds great then. I like the idea of community members being able to blog about something they are doing or some plugin they found interesting.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXyFtYGHL-JL4MHyp9CNLqmtpPB-MPWs9-Dfm_W%2BsWzbeQ%40mail.gmail.com.

[Gus Reiber]

exactly. I think that would be greatly valuable to a lot of people.

....so long as the browse and search interface of the site can handle the volume of content, and the volume of content is great enough that people think to look for it.

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

[Daniel Beck]

On 07.10.2015, at 17:05, Slide <slide...@gmail.com> wrote:

> Would the blog be available to anyone, or just CloudBees employees?

It's the Jenkins community blog, so the former -- but I suggest that we implement that using a model similar to core committership, in which occasional contributors do this via pull requests, and regular/known contributors get upgraded to commit access. The entire idea here is to open content writing up to more people, while making sure the content is high quality (given the expected exposure).

[Slide]

+1

--
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/B93DBFAD-4BCD-4E56-A04E-5EB65C1D5592%40beckweb.net.

[Kohsuke Kawaguchi]

I think you are being lot more ambitious than I am. All I imagined, at least for the time being, is a prominent call-to-action button that encourages people to sign up that creates an account to LDAP. Then maybe additional encouragement to follow @jenkinsci and sign up to the security advisory ML.

--

Kohsuke Kawaguchi

[Gus Reiber]

....from little acorns, grow...

--
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/EMbE3a4u8nA/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/CAN4CQ4z%2BHf1rCn5PheSz11gScc-vOmo18xbJnaqFdngYB2XPzw%40mail.gmail.com.

[Kohsuke Kawaguchi]

Exactly this. I feel like there's a disconnect. To me, it reads like we are actually mostly in agreement.

--
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/028BCF07-6D8C-4252-92F1-6AE52CED2C1E%40beckweb.net.

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

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

I re-read this and I think I understand you better.

2015-10-02 17:58 GMT-07:00 Daniel Beck <m...@beckweb.net>:

On 02.10.2015, at 20:17, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

> My key take away is that we can drive participation more by encouraging people to sign up and create an account, which converts them from anonymous drive-by visitors into a "card carrying member of the Jenkins community", which makes a lot of sense.

It's definitely in interesting concept.

The major problem I see with this is the need for moderation when everyone is allowed to post everywhere. And that doesn't even consider the manual work needed to correlate the work of numerous individual contributors as mentioned at the bottom. This requires that the moderator tools are exceptionally strong to not take up a lot of time.

So I'm re-reading "everyone is allowed to post everywhere" as "anyone can submit arbitrary PR that makes arbitrary changes" and "moderation" as "reviewing & merging PRs"

I thought how our Wiki works today in this regard is good. We let people make edits without any checks and 99% of them are good. Occasional offenders gets kicked out (thanks to larrys.)

Why does the same not work when we switch to PR? Banning spammers become a lot easier, and problems can be easily reverted.

Where is the new need for moderation?

One other issue that concerns me is that the vision requires a lot of participation to take off. Maybe I'm too pessimistic here, but I see a similar situation like those small business web sites with a section called 'special offers' or 'news' that is never updated. It just looks sad if e.g. you can vote on things in a list, and nothing has been voted on. A site should grow towards the described level of participation rather than go from basically nothing to that level. What do others think?

Our Wiki gets like 10 updates everyday. I think we can expect this level of participation to continue after switching from Confluence to Git+PR. Can you elaborate on what problems you are seeing?

--

Kohsuke Kawaguchi

[Gus Reiber]

So I have been somewhat hesitant of going with a flat-file approach, and I think that is the disconnect. I think a system that starts based on flat files is a little quicker to get off the ground, maybe, but a little tougher to things like guest authorship and the sort of graduated permissions that that might entail. I also think it makes it a little tougher to construct sophisticated content relationships.... relating a blog articles, to an event, to plugins, to user comments.... all easier if the content comes from a relational DB than if the content comes from flat files.

...but ease of authorship is the most important piece and it seems pretty clear from this thread anyway, that most Jenkins folks would rather submit a text file to a repo then type into a text form. ...so first problems first. You can always index flat files later or add various linky-bit-widgets to templates that help reaggregate content and add things like interactive comments and message threads.

....Slide gets the future bit that I am hoping to push towards, so I appreciate that quite a bit.

--
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/EMbE3a4u8nA/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/CAN4CQ4ycOmCXnogaKtL9aGtzd%3DvSW1t42auVoNQsrmEZLRCjtg%40mail.gmail.com.

[Daniel Beck]

On 07.10.2015, at 19:22, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

> Where is the new need for moderation?

Let me quote Gus' vision for the new site, from https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+2.0+Website+vision+from+Gus+Reiber :

> the right to establish a personal page and post blog articles, comment on the articles of others … Also implied by this emphasis is that comments and feedback mechanisms be associated with most if not all portions of content managed by the site. Visitors should be able to rate plugins, vote up or down on the value of a proposed feature, and comment on all written material.

Broken down:
- Every registered user gets to set up their own separate blog.
- Every registered user gets to comment on others' posts
- Most or even _all_ pages on the site will have a comment/feedback section.
- Visitors (which appears to mean "anonymous users") will be able to vote on plugins. This looks a lot like "Let's have an App Store for plugins", but without the "one review per credit card and purchase" limit of existing app stores, while at the same time much fewer users to balance potential vandalism.
- Visitors will be able to comment on _everything_. Basically like the wiki today, except you may not even need an account.

How is this NOT requiring a massive amount of moderation?

[Jesse Glick]

On Wed, Oct 7, 2015 at 1:34 PM, Daniel Beck <m...@beckweb.net> wrote:
> Visitors will be able to comment on _everything_. Basically like the wiki today

Wait, we are allowing comments on pages? Sounds like a bad idea. In
the current wiki these are often incorrect, digressive, misleading,
and/or misplaced. If you have something constructive to add to a
page’s contents, that everyone should see, file a PR and it should be
reviewed for content and style. If you just have some question or
whatever, take it to the mailing list.

[Gus Reiber]

It only requires a massive amount of moderation if a massive number of people sign up and start adding content.

Which to my mind, would be massively awesome. More likely, we will build the site and content authoring will trickle in.

If we invest in it, it will get better and the content flow will be greater.

....again, that is the world we want, I would think. Easier to moderate content than author it from scratch.

--
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/EMbE3a4u8nA/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/72A0606B-4F38-4A64-B103-E6ABC3656DE5%40beckweb.net.

[Daniel Beck]

On 07.10.2015, at 19:38, Jesse Glick <jgl...@cloudbees.com> wrote:

> Wait, we are allowing comments on pages? Sounds like a bad idea. In
> the current wiki these are often incorrect, digressive, misleading,
> and/or misplaced. If you have something constructive to add to a
> page’s contents, that everyone should see, file a PR and it should be
> reviewed for content and style. If you just have some question or
> whatever, take it to the mailing list.

This is exactly my concern.

It's a site with mostly static(ish) content, like documentation, not a content generating machine that doesn't care what was posted a week ago.

[Gus Reiber]

That is the other side of the coin.

Personally, I think no comments are worse than bad comments. No comments and it looks like the community is dead. Bad comments can be corrected, and will be corrected, if the site succeeds in generating an atmosphere of collaboration.

--
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/EMbE3a4u8nA/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/CANfRfr0_BDRrHkva8%2B%3DS5LK7Tk8%3D42ZmUZkbx3%3DaJBYFcjyG8A%40mail.gmail.com.

[Kohsuke Kawaguchi]

OK, so you were reacting to the input from Gus. That sure contains a lot of ideas that go far beyond what I originally proposed in the mega thread.

I also realize now that this summary wiki page could read as if the Gus vision is our plan of record, which is not the case.

We need to spend time writing down what our current proposal is.

--

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/72A0606B-4F38-4A64-B103-E6ABC3656DE5%40beckweb.net.

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

--

Kohsuke Kawaguchi

[Gus Reiber]

I agree that Doc is the most static content type and in some ways maybe the most important for this site...

...but if you look at the doc that is there now, when was it last updated and against which version of the product? It is reassuring (to me, anyway) to be able to open a comments list and see a date that is less than a year old. Then at least, I know someone has looked at this doc.

...otherwise, I think someone needs to commit to refreshing each page of the doc with each release of the product.

Maybe that is happening, but I can definitely find screens shots that are out of date.

--
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/EMbE3a4u8nA/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/6C41F856-5A48-48AF-B1F9-FC8092815AB3%40beckweb.net.

[Daniel Beck]

On 07.10.2015, at 19:41, Gus Reiber <gre...@cloudbees.com> wrote:

> Bad comments can be corrected, and will be corrected, if the site succeeds in generating an atmosphere of collaboration.

How well that works can be seen in the wiki. We don't really have moderation there, and the comment sections are a wasteland. They either should be page edits, questions on SO or the mailing lists, or not posted at all.

Since this isn't going to be a website where posts cycle quickly and everything older than a week disappears, we'll have comment sections with unanswered questions from years ago, just like some wiki pages. I'd prefer having no comment sections at all over those, and rather bundle discussions on the mailing list.

[Gus Reiber]

well.... our current site definitely shows signs of neglect.

In regards to the comments, it is hard to know what is the cause and what is the effect. A stale site looks the part. Ideally a good site generates some life of its own. Especially in a community case where you don't have a team or individual dedicated specifically to keeping everything nice.

...but I have made that pitch and seem to be mostly alone (with Slide) in my position.

--
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/EMbE3a4u8nA/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/2F9A2E8D-7A5D-4920-B231-9CC12CFF8B87%40beckweb.net.

[Andrew Bayer]

+1. This isn't a website that stands on its own - it's information about Jenkins. That's it.

A.

--

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/2F9A2E8D-7A5D-4920-B231-9CC12CFF8B87%40beckweb.net.

[Gus Reiber]

Slightly different tack.....

Does anyone have sites that they like that are similar to ours?

Though not a great parallel, because it is full of pictures, I quite like this community site:

https://www.behance.net/

In place of pictures, our site might feature plugins, but otherwise we could be similar in vibe, showing off contributions by community members.

I also use and like:

http://getbootstrap.com/

...this is a totally different approach. They just go straight into their doc, more or less, but still have a little splice where you can find blog articles and some news.

...anyone have any others that are a little closer to our domain?

--
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/EMbE3a4u8nA/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/CAPbPdOb268oZQMw02mA-edR23aOV5oDKTv9e_GaFJgXkSD_S1g%40mail.gmail.com.

[Andrew Bayer]

The bootstrap one is more in the right direction. 

A.

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

[Gus Reiber]

http://arquillian.org/ ...is another site I know KK likes. It is statically generated.

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

[Gus Reiber]

If we were to rank the value of our resources on jenkins-ci.org what would be on top?

If it were me, I would rank them like this:

1) the download

.

.

2) the plugins

.

3) the doc

4) events

5) the blog

....but I would like to see us do something a little more interesting with the blog so that it was up closer to the doc in value, since the doc is likely to be updated less frequently. I would also love to have some form of integration with this mailing list and the javadoc more elegantly mixed into the site. 

[Richard Bywater]

I think a major disconnect to me still looks like scope. In previous discussions it's been the Drupal side only but then in comments in this thread it starts crossing over to the Wiki side of things as well.

I don't know if it exists already but a guide to what content would be available to people and what "side of the fence" it would sit in would be useful.

Richard.

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

[Daniel Beck]

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?

[Daniel Beck]

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

[Kohsuke Kawaguchi]

+1.

This is basically what I was originally thinking, and my sense is that this is very close to what many of us want. 

--
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/0146B189-5C80-4098-A05C-CE833E5CF5B2%40beckweb.net.

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

--

Kohsuke Kawaguchi

[Gus Reiber]

I understand the urge to keep the scope manageable, but I am not sure I see in Daniel's list where the improvement is likely to come. It is a little concern of mine that we are emphasizing ease of authorship for a reasonably small subset of Jenkins users (those who write code) over the general usability of the site. ...but if we don't get content authored, it won't be much of site, so... pick your poison, I guess. 

None-the-less, I would think we would want to pick at least one area of the site where we were committing to actually making the site better, not just switching to what we believe will be a more convenient technology. My push back looks like this:

• I would have ordered your list of content areas by importance and placed plugins at or near the top. I think we are doing a bit of a hand wave there. It can and should be A LOT better than it is today, with browsing, searching, ratings and reviews. If we did that alone, we will have greatly advanced this site. Not doing so, I think, would be a big opportunity missed.
  
  
• Search seems to be missing from both the doc and the blog. I wouldn't say the blog is good today. You can't browse it and you cannot search it. Basically, if an article is more than a week old, good luck finding it. It might be that we just want to punt and port the blog to flat files and call that good. ...but if we want to make it better, the blog should be browsable by author, category and rating, as well as searchable. Any number of free-ware blog sites and tools offer these basics out of the box. 
  
  
• Doc needs to be searchable. Ideally it would also be integrated with technical blog posts and javadoc, If our website cannot offer search features at least equal to a free WordPress site, we should ask what we are doing and why we are doing it.
   
• Events need to be handled somehow in the new site. They are handled poorly in the current site. I am a little concerned they will be handled even worse in the new site. Again, I think a reasonable, and now surprisingly high bar should be event handling of equal quality to that which you might expect to get with a free WordPress site with an event widget added.
  
  
• I think limiting comments would be unfortunate, but I have made my pitch.

I guess that is sort of critical sounding. I hope not too much so.

If you look at any number of the 'instant website' hosting services (almost all of which have a free version), they have effectively set the bar so far above where Jenkins-ci.org is today, that I feel like we have the wrong benchmark. If we are going to take on the effort of making a custom site, rather than just grabbing a commodity site, I think what we build ourselves needs to be in some way better or at least equal to the commodity version.

...if we can't do better than a stock WordPress site, why wouldn't we just use a stock WordPress site? The bar has really come up a long way in the last 5 to 10 years. The good news is that a lot of these "fancy" features are now old-hat.

 

--
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/EMbE3a4u8nA/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/CAN4CQ4zPidLbdn5j04%3D-q%3D1G-hz7kFQ_uC2t65nvyaLfup1fvA%40mail.gmail.com.

[Daniel Beck]

On 08.10.2015, at 06:39, Gus Reiber <gre...@cloudbees.com> wrote:

> I understand the urge to keep the scope manageable, but I am not sure I see in Daniel's list where the improvement is likely to come. It is a little concern of mine that we are emphasizing ease of authorship for a reasonably small subset of Jenkins users (those who write code) over the general usability of the site. ...but if we don't get content authored, it won't be much of site, so... pick your poison, I guess.

Think about the kind of software Jenkins is. The least technical person to use Jenkins is probably an engineering manager, and I doubt they're going to contribute to the site. The vast majority of serious users are admins, developers, testers, or similar roles. All of them write code, at least scripts. All of them can handle text editors and don't think of Word when they hear that term.

> • I would have ordered your list of content areas by importance and placed plugins at or near the top. I think we are doing a bit of a hand wave there. It can and should be A LOT better than it is today, with browsing, searching, ratings and reviews. If we did that alone, we will have greatly advanced this site. Not doing so, I think, would be a big opportunity missed.

Absolutely agree. Plugins are important and we need something better than a flat list. Not sure about ratings/reviews (may be too high a bar for the initial release), but as I wrote, the plugins microsite can always be extended to cover more. One of the things that would make sense would be including popularity, both absolutely install count and recent growth.

Regarding ordering, it's essentially the one I'd use on the menu, in (mostly) increasing levels of involvement, rather than the weight placed on each section.

> • Search seems to be missing from both the doc and the blog. I wouldn't say the blog is good today. You can't browse it and you cannot search it. Basically, if an article is more than a week old, good luck finding it. It might be that we just want to punt and port the blog to flat files and call that good. ...but if we want to make it better, the blog should be browsable by author, category and rating, as well as searchable. Any number of free-ware blog sites and tools offer these basics out of the box.

> • Doc needs to be searchable. Ideally it would also be integrated with technical blog posts and javadoc, If our website cannot offer search features at least equal to a free WordPress site, we should ask what we are doing and why we are doing it.

I don't think I've ever used site search and been happy with the result. There's always something that isn't indexed, or it's stupidly broken in some way. If you want to look for something, you go to Google and search for "something jenkins". This has the added advantage of not caring whether something is on the site, the wiki (which will continue to exist for quite a while even if we decide to get rid of it), the mailing lists, or even Stack Overflow. Or does your free WordPress site index those?

That said, there appear to be solutions for site search when using Jekyll, so we may still be able to do something here. Or just do the custom Google search thing. It looks like it's 100 USD per year if we want it to look nice as well. A few years ago I used Google/Bing via API, I assume this still exists? That would make it integrate seamlessly into the site.

> • Events need to be handled somehow in the new site. They are handled poorly in the current site. I am a little concerned they will be handled even worse in the new site. Again, I think a reasonable, and now surprisingly high bar should be event handling of equal quality to that which you might expect to get with a free WordPress site with an event widget added.

So what specifically is missing? They are featured on the home/front page, and get their own page(s) to display them however makes sense.

> If you look at any number of the 'instant website' hosting services (almost all of which have a free version), they have effectively set the bar so far above where Jenkins-ci.org is today, that I feel like we have the wrong benchmark. If we are going to take on the effort of making a custom site, rather than just grabbing a commodity site, I think what we build ourselves needs to be in some way better or at least equal to the commodity version.
>
> ...if we can't do better than a stock WordPress site, why wouldn't we just use a stock WordPress site? The bar has really come up a long way in the last 5 to 10 years. The good news is that a lot of these "fancy" features are now old-hat.

I wrote what sites I looked at to build the proposal. They seem to be doing their job quite well.

One of the requirements repeatedly mentioned in the discussion is that this is the Jenkins site, and needs to offer documentation and downloads, so that's what I described. I don't think anyone but you and me even bothered mentioning the blog, events etc. -- so I'm already going beyond what appear to be the general requirements. Therefore I don't see where your need to somehow do more are coming from. It's certainly not result of the current discussion (or I _really_ missed something when I built the summary).

FWIW I kept the basic list of things we seem to move towards in this discussion and my proposal deliberately separate. One is the basic description of where the discussion seems to be going, the other is my "implementation" of that. While you addressed my proposal, most of what you wrote appears to fundamental that you should probably specifically address my summary of the discussion instead?

[Robert Sandell]

Do we have any site statistics on the current site of what pages are most frequently viewed? That could feed into a perhaps better discussion on what type of information to focus on.

One thing that makes me a bit uneasy in the discussion so far is the fact that both Daniel and Gus seems to glance over the "Documentation" part as just being a category and not that there are many important things behind that category.

To me one of the "selling points" of choosing Jenkins way back in the day was the meaning behind "Highly Extensible". It doesn't only mean that there are 1095 different plugins I can install, but that there is a possibility that I can make Jenkins do whatever I want.

Something that today is very front and center on the home page. By clicking the link "Extend Jenkins" I can learn how to do that (we can perhaps argue about the quality of the docs behind that link) but the fact that it's front and center on the page is an important notion to me and a very important feature of Jenkins itself and possible the biggest reason for us having such a wonderful and vibrant dev community could be attributed to the fact that users can "upgrade" themselves with just a click on the home page instead of diving into the depths of the documentation pages. And I think that's nothing to be glanced over and just put into the "Documentation" category.

Yes in the theme of 2.0 it is important to focus on new visitors/users, but I would argue that it's equally important to cater to the users that are coming back to the site after the initial experience, and make them want to come back for more in depth knowledge.

/B

--
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/DA032009-5DED-458C-80E9-634F89151A92%40beckweb.net.

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

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Nigel Magnay]

+1

I'd imagined something like www.git-scm.com. They've had over 100 individual contributors.

I'd completely bin comments. I don't see why the site needs to host a blog - why can't it just be links to Jenkins articles elsewhere.

Bigger requirements just end up sucking you towards the cpu-suck, security-nightmare and 'who has review/approve and commit bits' CRM nightmares like Wordpress.

--
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/0146B189-5C80-4098-A05C-CE833E5CF5B2%40beckweb.net.

[Kohsuke Kawaguchi]

2015-10-08 4:06 GMT-07:00 Nigel Magnay <nigel....@gmail.com>:

+1

I'd imagined something like www.git-scm.com. They've had over 100 individual contributors.

Yep, another static site backed by Git ... oh wait, it's actually a Rails app. Hmm.

 

I'd completely bin comments. I don't see why the site needs to host a blog - why can't it just be links to Jenkins articles elsewhere.

http://jenkins-ci.org/node is one of the few channels that we have to reach to users. So I hope everyone agrees that we should continue that, regardless of where it ends up to be.

The reason I advocate for putting it together with the website is (1) that's where it is today, and (2) this is one of the contents for which we want more contributors, so git+PR model helps.

 

Bigger requirements just end up sucking you towards the cpu-suck, security-nightmare and 'who has review/approve and commit bits' CRM nightmares like Wordpress.

On Thu, Oct 8, 2015 at 12:45 AM, 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?

--
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/0146B189-5C80-4098-A05C-CE833E5CF5B2%40beckweb.net.

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

--
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/CAPYP83TihgMF9gEGQXnpXF9%3DK6ETy2eNVhi-9sajXCgNC%2B4oMg%40mail.gmail.com.

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

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

2015-10-08 3:08 GMT-07:00 Robert Sandell <rsan...@cloudbees.com>:

Do we have any site statistics on the current site of what pages are most frequently viewed? That could feed into a perhaps better discussion on what type of information to focus on.

We have it connected to Google Analytics. I think Tyler has access to it but I don't.

 

One thing that makes me a bit uneasy in the discussion so far is the fact that both Daniel and Gus seems to glance over the "Documentation" part as just being a category and not that there are many important things behind that category.

To me one of the "selling points" of choosing Jenkins way back in the day was the meaning behind "Highly Extensible". It doesn't only mean that there are 1095 different plugins I can install, but that there is a possibility that I can make Jenkins do whatever I want.

Something that today is very front and center on the home page. By clicking the link "Extend Jenkins" I can learn how to do that (we can perhaps argue about the quality of the docs behind that link) but the fact that it's front and center on the page is an important notion to me and a very important feature of Jenkins itself and possible the biggest reason for us having such a wonderful and vibrant dev community could be attributed to the fact that users can "upgrade" themselves with just a click on the home page instead of diving into the depths of the documentation pages. And I think that's nothing to be glanced over and just put into the "Documentation" category.

Yes in the theme of 2.0 it is important to focus on new visitors/users, but I would argue that it's equally important to cater to the users that are coming back to the site after the initial experience, and make them want to come back for more in depth knowledge.

I think in due time the discussion will shift more and more to contents and less on tech. It's already happening!

And I fully agree that "extending Jenkins" is an important part of the value that we want to pitch.

I could really use somebody with an experience in this to guide us through, but what I thought Gus told me is that we first want to hash out what content we need to be on the website, then figure out which ones are more important and what personas we are targetting. Then how to organize the content kinda follow from there.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS3-H97zW8O%3DM2Y6r5BgYeuz7iFG1PFbKVDzWjzp%3De%3DX5A%40mail.gmail.com.

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

--

Kohsuke Kawaguchi

[Gus Reiber]

Yeah, so if I am understanding you correctly, Robert, you are saying that you would like to be able to highlight some bits of content over others? I would think that would just be a matter of marking particular content pieces with a tag that pushes them to the top of the homepage. It also sounds like you are suggesting these so marked articles should have some marketing-ish goop associated with them.

....Personally, I think the demonstration of Jenkins extensibility is more impressive than the saying of it. And, that demonstration is the plugins. Thus rather than an article that say 'hey look, we are extensible', I would think we would just want to go straight into showing off the plugins, just as http://getbootstrap.com/ goes straight into showing you Bootstrap or the Play store goes straight into showing you the Andoid apps or http://www.deviantart.com/ goes straight into showing you the art. To me, showing off the plugins screams extensibility and the content stays fresh by virtue of the fact that people are interacting with the plugins themselves. Sure we need to be able to get to blogs and events and doc, but so do these sites, and they do. Compare that with http://arquillian.org/, which is a prefectly fine site, but page 1 packs no punch in part becuase it lacks a particular angle to the story it wants to tell. Yawn, yawn, they have a blog.... and events and stuff...

What concerns me about the technology discussion, is that if you buy my pitch that the second most important thing Jenkins-ci.org does today (behind allowing the download of Jenkins) is hosting the plugins, there is a whole set of things we need to start doing in order to do that right. The essence of that effort will be blending metadata from the plugin author, community users, and a site curator and then serving that up to the user in a flexible fashion.

There are some real technical challenges there and if anything, it seems like moving to a more static site model is a move away from providing that value. Maybe not. I just am not seeing the glue that would hold the anonymous markdown files together. I am sure it can be done.

--
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/EMbE3a4u8nA/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/CAN4CQ4y0JwYDtSAdnmK6Zy6vpEVaN-NVpMo_d8MnzqTn9WyODg%40mail.gmail.com.

[Baptiste Mathus]

2015-10-08 20:36 GMT+02:00 Gus Reiber <gre...@cloudbees.com>:

Yeah, so if I am understanding you correctly, Robert, you are saying that you would like to be able to highlight some bits of content over others? I would think that would just be a matter of marking particular content pieces with a tag that pushes them to the top of the homepage. It also sounds like you are suggesting these so marked articles should have some marketing-ish goop associated with them.

....Personally, I think the demonstration of Jenkins extensibility is more impressive than the saying of it. And, that demonstration is the plugins. Thus rather than an article that say 'hey look, we are extensible', I would think we would just want to go straight into showing off the plugins, just as http://getbootstrap.com/ goes straight into showing you Bootstrap or the Play store goes straight into showing you the Andoid apps or http://www.deviantart.com/ goes straight into showing you the art. To me, showing off the plugins screams extensibility and the content stays fresh by virtue of the fact that people are interacting with the plugins themselves.

You convinced me Gus. 

IMO, we can indeed show off the plugins, showing the enormous numbers of themes where Jenkins can actually change its behaviour by being extensible and having been extended by plugins.

And in that list of things, I would imagine some list of themes/examples of customizations (i.e. plugins), and in the end some kind of sentence like "You didn't find the thing you're looking for? You can write write one plugin for your precise needs => link to 'how to extend by creating a plugin'".

 

Sure we need to be able to get to blogs and events and doc, but so do these sites, and they do. Compare that with http://arquillian.org/, which is a prefectly fine site, but page 1 packs no punch in part becuase it lacks a particular angle to the story it wants to tell. Yawn, yawn, they have a blog.... and events and stuff...

What concerns me about the technology discussion, is that if you buy my pitch that the second most important thing Jenkins-ci.org does today (behind allowing the download of Jenkins) is hosting the plugins, there is a whole set of things we need to start doing in order to do that right. The essence of that effort will be blending metadata from the plugin author, community users, and a site curator and then serving that up to the user in a flexible fashion.

+1. Showing off a list of plugins is a work per-se. Thinking out loud here, but I suppose the categorization's work going on for the wizard could somehow be reused/factorized here.

There are some real technical challenges there and if anything, it seems like moving to a more static site model is a move away from providing that value. Maybe not. I just am not seeing the glue that would hold the anonymous markdown files together. I am sure it can be done.

That would btw be another subject (flamewar?): would we stick to markdown, or asciidoc? (I'm for the latter... Markdown does not actually really exist, there are markdownS... Flavours etc.)

[Christopher Orr]

On 08/10/15 21:44, Baptiste Mathus wrote:
> 2015-10-08 20:36 GMT+02:00 Gus Reiber <gre...@cloudbees.com

> <mailto:gre...@cloudbees.com>>:

> ....Personally, I think the demonstration of Jenkins extensibility
> is more impressive than the saying of it. And, that demonstration is
> the plugins. Thus rather than an article that say 'hey look, we are
> extensible', I would think we would just want to go straight into
> showing off the plugins, just as http://getbootstrap.com/ goes
> straight into showing you Bootstrap or the Play store goes straight
> into showing you the Andoid apps or http://www.deviantart.com/ goes
> straight into showing you the art. To me, showing off the plugins
> screams extensibility and the content stays fresh by virtue of the
> fact that people are interacting with the plugins themselves.
>
> You convinced me Gus.
>
> IMO, we can indeed show off the plugins, showing the enormous numbers of
> themes where Jenkins can actually change its behaviour by being
> extensible and having been extended by plugins.

My question is: how do you "show off a plugin"?

Jenkins plugins aren't Bootstrap themes, nor are they Android apps — the
most you could show off for the vast majority of plugins would be a
screenshot of an ugly configuration form.

I'm not sure what "the content stays fresh" means in this context, and
who (and how) people are "interacting with the plugins" on the website?

Is the idea to have specially-written content (i.e. separate from the
wiki page that every plugin has), which highlights key plugins on the
main website?

Regards,
Chris

[Gus Reiber]

I think plugins are almost exactly like apps in an app store. Way back when I worked at Allaire, we (Mike Nimer and I) built a Developer's exchange that featured CFML applets and code snippets. That experience was designed very much like today's app-stores (but with older and crappier web-tech). It wasn't as sex as an app-store, but a lot sexier than random text articles. They also had interesting metadata that was associated with them, that again matches our plugins almost exactly: Their review ranking, installation share (% of Jenkins users using this plugin), a category badge  ...and though I have gotten negative pushback about this before, I don't think it would unreasonable to ask plugin authors to give their plugin an icon.

...something like this, but more of a website form factor than an in-app form factor:

https://www.youtube.com/watch?v=kcxKvyX4Oq8

https://www.youtube.com/watch?v=9vPUMe3lzfo

...the form factor isn't quite right for a website, but yeah, the sorting, grouping, categorizing is pretty close.

...the fresh content is new plugins or plugins that are freshly updated. The other fresh content is the reviews of those plugins. We can automate which plugins we show based on user feedback.

--
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/EMbE3a4u8nA/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/5616D1D0.4050609%40orr.me.uk.

[Christopher Orr]

Thanks for the explanation, and video! Do you have any old screenshots
of the Allaire stuff, out of curiosity?

That grid does seems nice, and yeah, we do know which plugins are newest
(I'm a fan of @jenkins_release) though I do prefer the version without
icons.. :)

Getting plugin developers to *name* their plugin in a reasonable (and
consistent) way is hard enough, never mind getting them to add a wiki
page, and then add a short but meaningful description there... so I'm
going to be pessimistic about icons, I'm afraid.

Regards,
Chris

> > <mailto:gre...@cloudbees.com <mailto:gre...@cloudbees.com>>>:

> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/5616D1D0.4050609%40orr.me.uk.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> 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

> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXyU-ExO7EJMK_LofNfhyffnV-Cp144rKLX8f9%3D-OpO2kQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAOcHHXyU-ExO7EJMK_LofNfhyffnV-Cp144rKLX8f9%3D-OpO2kQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Christopher Orr]

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

[Baptiste Mathus]

2015-10-08 23:06 GMT+02:00 Christopher Orr <ch...@orr.me.uk>:

Thanks for the explanation, and video!  Do you have any old screenshots
of the Allaire stuff, out of curiosity?

That grid does seems nice, and yeah, we do know which plugins are newest
(I'm a fan of @jenkins_release) though I do prefer the version without
icons.. :)

Getting plugin developers to *name* their plugin in a reasonable (and
consistent) way is hard enough, never mind getting them to add a wiki
page, and then add a short but meaningful description there... so I'm
going to be pessimistic about icons, I'm afraid.

(Yup, the governance meeting discussion about the required wiki page was, well, surprising... Anyway)

And at the same time, wouldn't those icons be at least an indicator of the liveliness of that plugin?

Don't get me wrong, I'm not saying icon is gonna change everything, but thinking about I suppose people (not necessarily maintainers themselves) would want to contribute icons to their favorite & useful plugins. So in the end, we may reach the goal: showing off most useful & active plugins first?

My 2 cents

[Daniel Beck]

On 08.10.2015, at 23:12, Christopher Orr <ch...@orr.me.uk> 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.

[Gus Reiber]

Oh no.... The internet never forgets!

...tonight I am going to party like it is 1999:

https://web.archive.org/web/20000816062846/http://devex.allaire.com/developer/gallery/index.cfm

...I take it back. 

App Stores are way, way, way sexier.

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/5616DAF0.7080405%40orr.me.uk.

[Robert Sandell]

I'm saying YES to showcase the plugins, but NO to hiding the extensibility way down the plugin list.

IMHO the extensibility documentation is equally important as the plugins themselves and the user and installation guides, i.e. it should not be more than one click (and no scrolling) from the main page to get to the "introduction to extending Jenkins" documentation with further links to everything else like the list of extension points, tutorials, javadoc etc.

I just wanted to highlight that so it doesn't disappear behind the "Documentation link" while discussing site content.

/B

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/CAOcHHXzY%2BBujzs1h-WDf6UYrk7%3DgN9QyKhVRPqBREr2kx1dA%2BA%40mail.gmail.com.

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

--

[Robert Sandell]

Back to the tech,

If we go for a static site generation with a PR model I believe we need to have the individual plugin pages distributed somehow, because if everything is centralized to one repo with a PR model then we could risk loosing the wonderful silo model we currently have with plugins. I think we would need some way for plugin devs to handle their documentation pages independantly of waiting for someone to approve and merge their PR.

Even if we give commit rights to frequent contributors of the site new plugin maintainers wouldn't necessarily get that access and will have problems releasing their plugin (since we nowadays require an existing wiki page in the pom).

But if we, as an example, gather them up in the site build process from the "jenkins-pages" branch of each plugin then there would be more autonomy for the plugin docs and they would get their silo back.

/B

[Richard Bywater]

Assuming the plugins moved into the static model and didn't remain in the Wiki side. Personally I think that perhaps we are trying to bite off too much in one chunk. Would a good starting point be taking a small part of the site (e.g. the Drupal + some basic getting started type stuff) and doing that first. From there people will have a much better idea on how its working and what will work and what won't.

In all of this I'd still like to have a discussion on how we might get Confluence up to a modern version which would, I think, allow for a lot of the "features" that we are looking for for some of the content at least.

Richard.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS14gS%3DZV3PbMRoya%2B1fSgT7q%3DPyqrjjQLJMSy7hLbksfg%40mail.gmail.com.

[Daniel Beck]

On 09.10.2015, at 12:18, Robert Sandell <rsan...@cloudbees.com> wrote:

> If we go for a static site generation with a PR model I believe we need to have the individual plugin pages distributed somehow, because if everything is centralized to one repo with a PR model then we could risk loosing the wonderful silo model we currently have with plugins. I think we would need some way for plugin devs to handle their documentation pages independantly of waiting for someone to approve and merge their PR.

In my proposal, the wiki pages would continue to live in the wiki for now. I realize that's not quite optimal, but as I wrote before, we don't need to define the 100% end state now, just the general direction. The initial release would definitely not have migrated any of the plugin content from the wiki, basically just replaced the flat list by categories we have today with a microsite that allowed better searching and filtering.

> On Fri, Oct 9, 2015 at 11:49 AM, Robert Sandell <rsan...@cloudbees.com> wrote:
> I'm saying YES to showcase the plugins, but NO to hiding the extensibility way down the plugin list.
> IMHO the extensibility documentation is equally important as the plugins themselves and the user and installation guides, i.e. it should not be more than one click (and no scrolling) from the main page to get to the "introduction to extending Jenkins" documentation with further links to everything else like the list of extension points, tutorials, javadoc etc.
>
> I just wanted to highlight that so it doesn't disappear behind the "Documentation link" while discussing site content.

For many of the menu items I'm thinking a drop-down (like on the current site, or centos.org) that provides access to the various sub-pages would be best. This seems a fair balance between not overloading the menu but still allowing quick access to sub-sections from the initial page. So having two sections "Use" and "Extend" in "Documentation" should be fine, moving the developer content out from "Contribute" in my current proposal.

We could also model the short introduction blurb about Jenkins on the home page after git-scm.com, where parts of the description link to certain sections of the site. Of course we'd mention "extensible" and that could link to the developer documentation.

WDYT?

[Robert Sandell]

> WDYT?

That could work, but I'm personally not fond of drop down menus as it tends to be a suboptimal experience on touch devices.

/B

--
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/332F496F-AC0B-4848-8613-9619901A77C2%40beckweb.net.

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

[Daniel Beck]

On 09.10.2015, at 12:43, Robert Sandell <rsan...@cloudbees.com> wrote:

> That could work, but I'm personally not fond of drop down menus as it tends to be a suboptimal experience on touch devices.

Check out how centos.org looks on your phone (or your browser at 770 or fewer pixels wide). Would that work?

[Daniel Beck]

On 09.10.2015, at 12:24, Richard Bywater <ric...@byh2o.com> wrote:

> In all of this I'd still like to have a discussion on how we might get Confluence up to a modern version which would, I think, allow for a lot of the "features" that we are looking for for some of the content at least.

Updating to a more modern Confluence version would be great. But I wonder what that would mean for the future site plans.

What I mean by that is that it still would not address any of the following, all of which have been mentioned in the course of this discussion (and not just by me ;-) ):

- Terrible comments everywhere and nobody to moderate them
- No review of any documentation updates or additions, and there's value in having some well structured and reviewed docs
- Some prefer "wiki syntax" editing and Confluence only offers WYSIWYG in newer versions I think
- UX disconnect when moving immediately from the site to the wiki as today

OTOH the advantage is easier editing in the browser. But I think we can make this relatively easy on the new site as well. For that I've set up a VERY minimal demo of what we could do:

http://daniel-beck.github.io/jenkins-site-demo/
(The repo for this is https://github.com/daniel-beck/jenkins-site-demo )

It's basically the default generated Jekyll site, with a minor addition: If you visit "About" or "Welcome to Jekyll!", both pages offer to "Improve this page", linking to the GitHub editing interface. If you don't have commit access, GitHub will fork, branch, and create a PR.

Feel free to play around with this a bit. Ping me on IRC if you want me to merge a PR.

[James Nord]

scrolling is so last decade.  swiping is the new scrolling and to be critical on a mobile that web site is way to "blah blah blah"...  "all that centos7 junk junk before I get to the news section (a lot of scrolling!)  :-)

What is CentOS anyway - as that site doesn't tell me :-P

[Gus Reiber]

I think the talk of scrolling and hover menus is a giant red-herring.

The form factor of the pages needs to be malleable and determined at least in part by the device requesting the information.

We should not be trying to build a website from the toolbar menu down.

We shouldn't be writing a new homepage, we should be fixing a broken site.

Please, please, please, look at the list of content areas in the site and prioritize them first. Then set about fixing the most important areas first. It is fairly trivial wrap well executed content areas into an attractive homepage or global nav and it is helpful to know how far the areas of value have come in terms of improvement before we start illustrating the front door for the site.

To make this clearer...

...I pointed out that event handling on the current site is badly broken, to which Daniel replied, 'how so'?

Here's how so....

    Office hours is the communities most recurring event. You can find them on the calendar here. But you cannot get any information about them, unless you go here. From a site visitor's perspective, unless you were already familiar with our office hours, you would have no idea what that was, assuming you were even lucky enough to find the link hidden in the pull down menu. If you are looking for it, you can find events, but when you click on the goofy Google month page, you get no information about what the events you see on the calendar actually are. Even if you click into an office hour link you get absolutely no information about what an 'office hour' even is, let alone what is going to be discussed. 

....should I go to an office hour, or any other event on the events page?

I have no idea.

This is true of every event in the site.

If there is going to be a big event, there is probably a blog post about it. But that blog post looks like every other blog post, so if I am looking for an event in particular (because I want to go and meet people in the community, or just know what is going on), do I know I should be reading through the blog posts to weed out the events?

Let's say we wanted out site to have a community focus...

....so we didn't just want a single webmaster scheduling events, but we wanted community members to come and register their own events. How would they do that? Are they going to know that to really register an event, they will need to make other pages and blog posts promoting that event and maintain that information separately?

This is a super fixable technical problem. Been fixed 1000 times over.

But it isn't fixed by a new nav menu or by a new homepage. And we are not taking advantages of the well known fixes that exist.

...again, this isn't to say events is the most important content area in the site and needs immediate attention, but I would say most areas of the site are poorly handled, much like our events. Since it is unlikely we can fix it all for the amount of investment we have to give it, I think we should pick an area we are doing poorly and start doing it well.

...rinse... repeat.

I would start with the plugins and rather than events or blogs or doc (their shortcomings are less glaring and their upside is smaller).

 

--
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/EMbE3a4u8nA/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/a192a678-7fdc-4f92-8955-f54ba8adfe40%40googlegroups.com.

[R. Tyler Croy]

TOP POSTING because holy mega-thread batman! :)

What I see happening here is solutions being mixed up with problem statements

The top-level goals, in my opinion are (in no particular order):

* Make a good usable site, that looks good and connects visitors with the
information that is relevant to them as quickly as is possible (note: this
does not necessitate that all content lives on-site)

* Enable members of the community, ourselves included, to quickly and easily
manage and contribute content to the site


These aren't mutually exclusive goals.


I think this thread has been good in surfacing lots of ideas and opinions about
jenkins-ci.org, but what I'd like to do now is spend a little bit of time doing
like Daniel did and throw up a prototype or two. I have some ideas around
asciidoctor(.org) and an actual site-build process which can morph static
content into a more "live" site.


Anyways, if you're passionate about the subject, fleshing out ideas and
proposals in confluence is IMHO the best path forward.


Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 3F51E16F
------------------------------------------------------

[Richard Bywater]

Tried out the demo you had setup - overall I think it is good for content that doesn't change too often but I worry about content that changes on a regular basis or trying to get somebody who isn't that upskilled in things like GitHub to understand and follow the process. (e.g. The fact that after making a change you then have to click on the "Create a PR request button" and then you need to work out how to get back to where you were on the site type thing)

Now I'm not terribly tied to Confluence (even though me going on about it so much might look like it :) ) but figured I'd provide some counter-argument to your points:

- Terrible comments everywhere and nobody to moderate them

I'd say to solve this you'd either turn comments off completely or use something like https://marketplace.atlassian.com/plugins/com.bugsio.confluence.plugins.external-comments to use Disqus instead

- No review of any documentation updates or additions, and there's value in having some well structured and reviewed docs

Agreed although the counter to this is that then there's a delay in getting your content live and requires someone to actively traverse the approval queue. In Confluence there's also some options for this type of things by the looks (although never looked at them myself) : https://confluence.atlassian.com/pages/viewpage.action?pageId=179438967

- Some prefer "wiki syntax" editing and Confluence only offers WYSIWYG in newer versions I think

I'd say there's also a large number of people who prefer WYSIWYG as well - this probably comes down to the audience of who we are expecting to make changes. For me, I don't deal in Markdown all day and so Markdown is a (re)learning experience everytime I come to it :)

- UX disconnect when moving immediately from the site to the wiki as today

Agreed by default you get this but you I think that could be fixed with some work. For instance, as I've previously posted it, some of Atlassian's site is now powered by https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-viewport which allows to make Wiki pages look a bit more "normal"

Also just one more thing to mention that comes to mind about the fact that we possibly wouldn't want to use the cloud version of Confluence due to it not integrating with our LDAP, wouldn't a Github based solution suffer from the same problem? (Yes, quite a large number of people have a Github account, but its still not linked in with our LDAP and is therefore just a separate account off to one side)

Just some more food for thought! 

Richard.

--
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/DEB7C637-C3AB-417A-9651-B76CBB2A3F4C%40beckweb.net.

[Kohsuke Kawaguchi]

2015-10-09 14:34 GMT-07:00 R. Tyler Croy <ty...@monkeypox.org>:

What I see happening here is solutions being mixed up with problem statements

   ...

Anyways, if you're passionate about the subject, fleshing out ideas and
proposals in confluence is IMHO the best path forward.

Let me put my traffic cop hat on...

I called up Gus and asked him to help me structure the conversation because there are a lot of things getting discussed here and it's hard to keep track of. Good thoughts are getting buried as this thread continues to grow.

He gave me the run-down on how does one go about a website project like this, which I captured in the "project structure" section of this Wiki page. I'd like to ask all of us in this thread to take a moment and read that.

I think it makes sense to try to segregate conversations along those track lines, then frame discussions per segments.

I'm going to start a separate thread for each track. Let's close down this thread. 

--

Kohsuke Kawaguchi