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 <https://issues.jenkins-ci.org/browse/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 <https://help.github.com/articles/creating-a-pull-request/> 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 <[email protected]>: > 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 > > On Wed, 30 Sep 2015 3:40 pm R. Tyler Croy <[email protected]> wrote: > >> (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>. >> > >> > 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 >> > <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 [email protected]. >> > 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 >> ------------------------------------------------------ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/20150930023726.GG2353%40blackberry.coupleofllamas.com >> . >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAMui944W6b%2BPc%2BDekJzBi7nkySeDBYCeswtnZqejBAoOgfVUaA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAMui944W6b%2BPc%2BDekJzBi7nkySeDBYCeswtnZqejBAoOgfVUaA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zzf2uvL5Cb%3D%3DpBbwNxBf-pYdG8m5qZaEtVvJE7nc9zyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
