Camel › Camel Development

helping out with the Web site

Classic

List

Threaded

38 messages Options

Eric Johnson

helping out with the Web site

I'm a committer on CXF and have been helping out with the ServiceMix
site redesign. I'm interested in helping Camel maintain its Web site
as well. Are there any tasks that need tackling that I can get started
on?

--
Principle Technical Writer
Phone (781) 280-4174
Skype finnmccumial
E-Mail [hidden email]
Blog http://documentingit.blogspot.com/

Richard Kettelerij

Re: helping out with the Web site

FYI, http://camel.465427.n5.nabble.com/DISCUSS-Apache-Camel-website-facelift-td3202031.html#a3202031

hadrian

Re: helping out with the Web site

In reply to this post by Eric Johnson

Eric, nice to hear from you. I've seen you busy with Karaf and SMX.

Yes, absolutely. We talked in Aug about aligning as much as possible the AMQ/SMX/Karaf/Camel sites as much a possible. Not sure how much that would be possible with CXF. The rationale for that is that many users use these projects together (as the recent survey shows, and I will publish the results shortly) and it would be good to provide a similar navigating experience. I also saw the templates splatch proposed for SMX and they look pretty cool. I think he's still working on a Camel logo.

If you want to take ownership and drive this, you are more than welcome. Please let me know if you need any help. We could start with a page proposing a new look-and-feel and let the community vote.

We highly appreciate your contribution,
Hadrian

On Nov 9, 2010, at 2:44 PM, Eric Johnson wrote:

> I'm a committer on CXF and have been helping out with the ServiceMix
> site redesign. I'm interested in helping Camel maintain its Web site
> as well. Are there any tasks that need tackling that I can get started
> on?
>
> --
> Principle Technical Writer
> Phone (781) 280-4174
> Skype finnmccumial
> E-Mail [hidden email]
> Blog http://documentingit.blogspot.com/

hadrian

Re: helping out with the Web site

In reply to this post by Richard Kettelerij

Thanks Richard. I am glad somebody noticed that, because there was no response. However there was a lot of related activity on Karaf and SMX following my post.

Cheers,
Hadrian

On Nov 9, 2010, at 3:15 PM, Richard Kettelerij wrote:

>
> FYI,
> http://camel.465427.n5.nabble.com/DISCUSS-Apache-Camel-website-facelift-td3202031.html#a3202031
> --
> View this message in context: http://camel.465427.n5.nabble.com/helping-out-with-the-Web-site-tp3257543p3257592.html
> Sent from the Camel Development mailing list archive at Nabble.com.

Eric Johnson

Re: helping out with the Web site

In reply to this post by hadrian

Hadrian,
Lukasz is polishing up the SMX design this week. It looks pretty
snazy. Hopefully it will be integrated into the Sacalte generated
pilot project soon.
A wiki page for proposals is a good idea. I can post a link to the
proposed design for SMX and use that as a starting point for the
discussion.
Can I just start a page or does someone else need to do it?
Cheers,
Eric

On Tue, Nov 9, 2010 at 3:19 PM, Hadrian Zbarcea <[hidden email]> wrote:

> Eric, nice to hear from you. I've seen you busy with Karaf and SMX.
>
> Yes, absolutely. We talked in Aug about aligning as much as possible the AMQ/SMX/Karaf/Camel sites as much a possible. Not sure how much that would be possible with CXF. The rationale for that is that many users use these projects together (as the recent survey shows, and I will publish the results shortly) and it would be good to provide a similar navigating experience. I also saw the templates splatch proposed for SMX and they look pretty cool. I think he's still working on a Camel logo.
>
> If you want to take ownership and drive this, you are more than welcome. Please let me know if you need any help. We could start with a page proposing a new look-and-feel and let the community vote.
>
> We highly appreciate your contribution,
> Hadrian
>
>
> On Nov 9, 2010, at 2:44 PM, Eric Johnson wrote:
>
>> I'm a committer on CXF and have been helping out with the ServiceMix
>> site redesign. I'm interested in helping Camel maintain its Web site
>> as well. Are there any tasks that need tackling that I can get started
>> on?
>>
>> --
>> Principle Technical Writer
>> Phone (781) 280-4174
>> Skype finnmccumial
>> E-Mail [hidden email]
>> Blog http://documentingit.blogspot.com/
>
>

--
Principle Technical Writer
Phone (781) 280-4174
Skype finnmccumial
E-Mail [hidden email]
Blog http://documentingit.blogspot.com/

hadrian

Re: helping out with the Web site

Eric, you can do it. I made sure you have the right karma (based on your icla filed with the ASF).

Cheers,
Hadrian

On Nov 9, 2010, at 3:34 PM, Eric Johnson wrote:

> Hadrian,
> Lukasz is polishing up the SMX design this week. It looks pretty
> snazy. Hopefully it will be integrated into the Sacalte generated
> pilot project soon.
> A wiki page for proposals is a good idea. I can post a link to the
> proposed design for SMX and use that as a starting point for the
> discussion.
> Can I just start a page or does someone else need to do it?
> Cheers,
> Eric
>
> On Tue, Nov 9, 2010 at 3:19 PM, Hadrian Zbarcea <[hidden email]> wrote:
>> Eric, nice to hear from you. I've seen you busy with Karaf and SMX.
>>
>> Yes, absolutely. We talked in Aug about aligning as much as possible the AMQ/SMX/Karaf/Camel sites as much a possible. Not sure how much that would be possible with CXF. The rationale for that is that many users use these projects together (as the recent survey shows, and I will publish the results shortly) and it would be good to provide a similar navigating experience. I also saw the templates splatch proposed for SMX and they look pretty cool. I think he's still working on a Camel logo.
>>
>> If you want to take ownership and drive this, you are more than welcome. Please let me know if you need any help. We could start with a page proposing a new look-and-feel and let the community vote.
>>
>> We highly appreciate your contribution,
>> Hadrian
>>
>>
>> On Nov 9, 2010, at 2:44 PM, Eric Johnson wrote:
>>
>>> I'm a committer on CXF and have been helping out with the ServiceMix
>>> site redesign. I'm interested in helping Camel maintain its Web site
>>> as well. Are there any tasks that need tackling that I can get started
>>> on?
>>>
>>> --
>>> Principle Technical Writer
>>> Phone (781) 280-4174
>>> Skype finnmccumial
>>> E-Mail [hidden email]
>>> Blog http://documentingit.blogspot.com/
>>
>>
>
>
>
> --
> Principle Technical Writer
> Phone (781) 280-4174
> Skype finnmccumial
> E-Mail [hidden email]
> Blog http://documentingit.blogspot.com/

Łukasz Dywicki

RE: helping out with the Web site

Hi,
We working on SMX/Karaf so we basically stuck a bit in current stuff. But
don't worries, we going to continue working with Camel community too. We
just need to finish one task to avoid designer overload.

Best regards,
Lukasz

-----Original Message-----
From: Hadrian Zbarcea [mailto:[hidden email]]
Sent: Tuesday, November 09, 2010 10:04 PM
To: [hidden email]
Subject: Re: helping out with the Web site

Eric, you can do it. I made sure you have the right karma (based on your
icla filed with the ASF).

Cheers,
Hadrian

On Nov 9, 2010, at 3:34 PM, Eric Johnson wrote:

wrote:
>> Eric, nice to hear from you. I've seen you busy with Karaf and SMX.
>>
>> Yes, absolutely. We talked in Aug about aligning as much as possible the
AMQ/SMX/Karaf/Camel sites as much a possible. Not sure how much that would
be possible with CXF. The rationale for that is that many users use these
projects together (as the recent survey shows, and I will publish the
results shortly) and it would be good to provide a similar navigating
experience. I also saw the templates splatch proposed for SMX and they look
pretty cool. I think he's still working on a Camel logo.
>>
>> If you want to take ownership and drive this, you are more than welcome.
Please let me know if you need any help. We could start with a page
proposing a new look-and-feel and let the community vote.

>>
>> We highly appreciate your contribution,
>> Hadrian
>>
>>
>> On Nov 9, 2010, at 2:44 PM, Eric Johnson wrote:
>>
>>> I'm a committer on CXF and have been helping out with the ServiceMix
>>> site redesign. I'm interested in helping Camel maintain its Web site
>>> as well. Are there any tasks that need tackling that I can get started
>>> on?
>>>
>>> --
>>> Principle Technical Writer
>>> Phone (781) 280-4174
>>> Skype finnmccumial
>>> E-Mail [hidden email]
>>> Blog http://documentingit.blogspot.com/
>>
>>
>
>
>
> --
> Principle Technical Writer
> Phone (781) 280-4174
> Skype finnmccumial
> E-Mail [hidden email]
> Blog http://documentingit.blogspot.com/

jstrachan

Re: helping out with the Web site

In reply to this post by Eric Johnson

FWIW I started an experimental spike to try recreate the Camel website
using wiki files from source control - exported from Confluence -
(rather than the Confluence / AutoExport icky stuff) like Karaf &
ServiceMix are doing. More as a test of Scalate than any attempt to
actually change any documentation. (I didn't actually touch any of the
Camel documentation at all; just tweaked the layout/Scalate stuff to
get it just about working)...

https://github.com/jstrachan/camel-docs

Looks like we've one or two fairly trivial confluence macros to
implement & a couple of wikitext bugs to have a faithful reproduction
of the site, but its not a bad start.

e.g. do this...

git clone https://github.com/jstrachan/camel-docs.git
cd camel-docs
mvn jetty:run

then see these pages which don't quite work :(...

http://localhost:8080/documentation/enterprise-integration-patterns.html
http://localhost:8080/documentation/components.html

On 9 November 2010 19:44, Eric Johnson <[hidden email]> wrote:

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

hadrian

Re: helping out with the Web site

Thanks James,

You have to comment out the dependency on scalate-test in the pom for this to work (otherwise you get a "Failed to resolve artifact").

That aside, one of the important requirements I believe is not to raise the barrier to entry for those who want to contribute documentation. Today, one only needs to have a icla signed at apache and edit the wiki in place. How is this solved? We talked about being able to edit in place and a patch being generated and added to a jira at apache. I don't see any support for that. Is that still the plan?

Cheers,
Hadrian

On Nov 10, 2010, at 5:50 AM, James Strachan wrote:

> FWIW I started an experimental spike to try recreate the Camel website
> using wiki files from source control - exported from Confluence -
> (rather than the Confluence / AutoExport icky stuff) like Karaf &
> ServiceMix are doing. More as a test of Scalate than any attempt to
> actually change any documentation. (I didn't actually touch any of the
> Camel documentation at all; just tweaked the layout/Scalate stuff to
> get it just about working)...
>
> https://github.com/jstrachan/camel-docs
>
> Looks like we've one or two fairly trivial confluence macros to
> implement & a couple of wikitext bugs to have a faithful reproduction
> of the site, but its not a bad start.
>
> e.g. do this...
>
> git clone https://github.com/jstrachan/camel-docs.git
> cd camel-docs
> mvn jetty:run
>
> then see these pages which don't quite work :(...
>
> http://localhost:8080/documentation/enterprise-integration-patterns.html
> http://localhost:8080/documentation/components.html
>
>
>
> On 9 November 2010 19:44, Eric Johnson <[hidden email]> wrote:
>> I'm a committer on CXF and have been helping out with the ServiceMix
>> site redesign. I'm interested in helping Camel maintain its Web site
>> as well. Are there any tasks that need tackling that I can get started
>> on?
>>
>> --
>> Principle Technical Writer
>> Phone (781) 280-4174
>> Skype finnmccumial
>> E-Mail [hidden email]
>> Blog http://documentingit.blogspot.com/
>>
>
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration

Guillaume Nodet

Re: helping out with the Web site

Administrator

On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea <[hidden email]> wrote:
> Thanks James,
>
> You have to comment out the dependency on scalate-test in the pom for this to work (otherwise you get a "Failed to resolve artifact").
>
> That aside, one of the important requirements I believe is not to raise the barrier to entry for those who want to contribute documentation. Today, one only needs to have a icla signed at apache and edit the wiki in place.

This can be done by submitting a patch attached to Jira.

> How is this solved? We talked about being able to edit in place and a patch being generated and added to a jira at apache. I don't see any support for that. Is that still the plan?

I agree that would be a good idea. I suppose redirecting to a live
webapp hosted on some zone at the ASF would work. We just need to
actually write that web app ;-)

>
> Cheers,
> Hadrian
>
>
> On Nov 10, 2010, at 5:50 AM, James Strachan wrote:
>
>> FWIW I started an experimental spike to try recreate the Camel website
>> using wiki files from source control - exported from Confluence -
>> (rather than the Confluence / AutoExport icky stuff) like Karaf &
>> ServiceMix are doing. More as a test of Scalate than any attempt to
>> actually change any documentation. (I didn't actually touch any of the
>> Camel documentation at all; just tweaked the layout/Scalate stuff to
>> get it just about working)...
>>
>> https://github.com/jstrachan/camel-docs
>>
>> Looks like we've one or two fairly trivial confluence macros to
>> implement & a couple of wikitext bugs to have a faithful reproduction
>> of the site, but its not a bad start.
>>
>> e.g. do this...
>>
>> git clone https://github.com/jstrachan/camel-docs.git
>> cd camel-docs
>> mvn jetty:run
>>
>> then see these pages which don't quite work :(...
>>
>> http://localhost:8080/documentation/enterprise-integration-patterns.html
>> http://localhost:8080/documentation/components.html
>>
>>
>>
>> On 9 November 2010 19:44, Eric Johnson <[hidden email]> wrote:
>>> I'm a committer on CXF and have been helping out with the ServiceMix
>>> site redesign. I'm interested in helping Camel maintain its Web site
>>> as well. Are there any tasks that need tackling that I can get started
>>> on?
>>>
>>> --
>>> Principle Technical Writer
>>> Phone (781) 280-4174
>>> Skype finnmccumial
>>> E-Mail [hidden email]
>>> Blog http://documentingit.blogspot.com/
>>>
>>
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: jstrachan
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>
>

--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

jstrachan

Re: helping out with the Web site

In reply to this post by hadrian

On 10 November 2010 13:40, Hadrian Zbarcea <[hidden email]> wrote:
> Thanks James,
>
> You have to comment out the dependency on scalate-test in the pom for this to work (otherwise you get a "Failed to resolve artifact").
>
> That aside, one of the important requirements I believe is not to raise the barrier to entry for those who want to contribute documentation. Today, one only needs to have a icla signed at apache and edit the wiki in place. How is this solved?

Anyone can submit a patch using the traditional SVN mechanism just
like for patches to code or build files - or by forking the Camel
repository at Github.com, editing the entire website there and pushing
the change back to us. The benefit is folks can now do things like
grep & search/replace to fix up bad links or whatever.

In either case, whether folks are committers or not, whether they use
our svn checkout or a git clone, folks get to edit the wiki files and
actually see what the website is really going to look like before they
commit/send a patch. Currently the only way to see how the site will
look after a documentation change is to make the change, then hope
that in a few hours AutoExport will re-render the page and the Apache
web cache will eventually refresh. If includes or navigation is
changed you usually have to wait for an administrator to run
AutoExport on the entire site...

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

dkulp@apache.org

Re: helping out with the Web site

In reply to this post by Guillaume Nodet

On Wednesday 10 November 2010 9:43:13 am Guillaume Nodet wrote:

> On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea <[hidden email]> wrote:
> > Thanks James,
> >
> > You have to comment out the dependency on scalate-test in the pom for
> > this to work (otherwise you get a "Failed to resolve artifact").
> >
> > That aside, one of the important requirements I believe is not to raise
> > the barrier to entry for those who want to contribute documentation.
> > Today, one only needs to have a icla signed at apache and edit the wiki
> > in place.
>
> This can be done by submitting a patch attached to Jira.

Which is still a fairly high barrier. For CXF, we recently got a volunteer
that has been doing a WONDERFUL job cleaning up various pages on the website.
That individual has dived right in and started working on thing. He's also
logged some JIRA issues about updating javadoc and warnings and such, but I'm
having problems working with him to get patches created. For some people,
working with something like svn or git or even maven is a challenge. It is
more stuff to install (everyone has a browser installed) and learn.

For most of the people on this list, it ISN'T a big deal. We deal with svn
and mvn every day. For others, it could be.

> > How is this solved? We talked about being able to edit in place and a
> > patch being generated and added to a jira at apache. I don't see any
> > support for that. Is that still the plan?
>
> I agree that would be a good idea. I suppose redirecting to a live
> webapp hosted on some zone at the ASF would work. We just need to
> actually write that web app ;-)

Now THAT is an interesting idea. :-)

Dan

>
> > Cheers,
> > Hadrian
> >
> > On Nov 10, 2010, at 5:50 AM, James Strachan wrote:
> >> FWIW I started an experimental spike to try recreate the Camel website
> >> using wiki files from source control - exported from Confluence -
> >> (rather than the Confluence / AutoExport icky stuff) like Karaf &
> >> ServiceMix are doing. More as a test of Scalate than any attempt to
> >> actually change any documentation. (I didn't actually touch any of the
> >> Camel documentation at all; just tweaked the layout/Scalate stuff to
> >> get it just about working)...
> >>
> >> https://github.com/jstrachan/camel-docs
> >>
> >> Looks like we've one or two fairly trivial confluence macros to
> >> implement & a couple of wikitext bugs to have a faithful reproduction
> >> of the site, but its not a bad start.
> >>
> >> e.g. do this...
> >>
> >> git clone https://github.com/jstrachan/camel-docs.git
> >> cd camel-docs
> >> mvn jetty:run
> >>
> >> then see these pages which don't quite work :(...
> >>
> >> http://localhost:8080/documentation/enterprise-integration-patterns.html
> >> http://localhost:8080/documentation/components.html
> >>
> >> On 9 November 2010 19:44, Eric Johnson <[hidden email]> wrote:
> >>> I'm a committer on CXF and have been helping out with the ServiceMix
> >>> site redesign. I'm interested in helping Camel maintain its Web site
> >>> as well. Are there any tasks that need tackling that I can get started
> >>> on?
> >>>
> >>> --
> >>> Principle Technical Writer
> >>> Phone (781) 280-4174
> >>> Skype finnmccumial
> >>> E-Mail [hidden email]
> >>> Blog http://documentingit.blogspot.com/
> >>
> >> --
> >> James
> >> -------
> >> FuseSource
> >> Email: [hidden email]
> >> Web: http://fusesource.com
> >> Twitter: jstrachan
> >> Blog: http://macstrac.blogspot.com/
> >>
> >> Open Source Integration

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog

hadrian

Re: helping out with the Web site

In reply to this post by Guillaume Nodet

Yeah, that's what I mean and what I believe was discussed in Aug. Hosting it at the ASF (or somewhere) I don't think would be a problem.
Guillaume, I assume we'd deploy the webapp in Karaf, correct? ;)

On a second thought, since a few projects plan on using it, what about incubating it at the ASF?

Hadrian

On Nov 10, 2010, at 9:43 AM, Guillaume Nodet wrote:

> On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea <[hidden email]> wrote:
>> Thanks James,
>>
>> You have to comment out the dependency on scalate-test in the pom for this to work (otherwise you get a "Failed to resolve artifact").
>>
>> That aside, one of the important requirements I believe is not to raise the barrier to entry for those who want to contribute documentation. Today, one only needs to have a icla signed at apache and edit the wiki in place.
>
> This can be done by submitting a patch attached to Jira.
>
>> How is this solved? We talked about being able to edit in place and a patch being generated and added to a jira at apache. I don't see any support for that. Is that still the plan?
>
> I agree that would be a good idea. I suppose redirecting to a live
> webapp hosted on some zone at the ASF would work. We just need to
> actually write that web app ;-)
>
>>
>> Cheers,
>> Hadrian
>>
>>
>> On Nov 10, 2010, at 5:50 AM, James Strachan wrote:
>>
>>> FWIW I started an experimental spike to try recreate the Camel website
>>> using wiki files from source control - exported from Confluence -
>>> (rather than the Confluence / AutoExport icky stuff) like Karaf &
>>> ServiceMix are doing. More as a test of Scalate than any attempt to
>>> actually change any documentation. (I didn't actually touch any of the
>>> Camel documentation at all; just tweaked the layout/Scalate stuff to
>>> get it just about working)...
>>>
>>> https://github.com/jstrachan/camel-docs
>>>
>>> Looks like we've one or two fairly trivial confluence macros to
>>> implement & a couple of wikitext bugs to have a faithful reproduction
>>> of the site, but its not a bad start.
>>>
>>> e.g. do this...
>>>
>>> git clone https://github.com/jstrachan/camel-docs.git
>>> cd camel-docs
>>> mvn jetty:run
>>>
>>> then see these pages which don't quite work :(...
>>>
>>> http://localhost:8080/documentation/enterprise-integration-patterns.html
>>> http://localhost:8080/documentation/components.html
>>>
>>>
>>>
>>> On 9 November 2010 19:44, Eric Johnson <[hidden email]> wrote:
>>>> I'm a committer on CXF and have been helping out with the ServiceMix
>>>> site redesign. I'm interested in helping Camel maintain its Web site
>>>> as well. Are there any tasks that need tackling that I can get started
>>>> on?
>>>>
>>>> --
>>>> Principle Technical Writer
>>>> Phone (781) 280-4174
>>>> Skype finnmccumial
>>>> E-Mail [hidden email]
>>>> Blog http://documentingit.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> James
>>> -------
>>> FuseSource
>>> Email: [hidden email]
>>> Web: http://fusesource.com
>>> Twitter: jstrachan
>>> Blog: http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com

jstrachan

Re: helping out with the Web site

In reply to this post by Guillaume Nodet

On 10 November 2010 14:43, Guillaume Nodet <[hidden email]> wrote:

Its pretty easy to have a static website have an 'edit this page' type
link on the static HTML which just populates a <textarea> using jQuery
so users can edit the wiki content of the page. I've done this on a
few FuseForge sites in the past.

The tricky bit is having the web app to accept the POST which should
then take the new changed page and submit a JIRA or something. I'm
hoping GitHub will add something like this to their git-based-wiki
stuff they are doing; they've already got the awesome code review
stuff & pull request queue (so its easy for commiters to review a
patch and just apply it with one click).

Be that as it may; having an 'edit this page' link on the static HTML
site is a nice to have. Its very easy for folks to check out the
project from our svn and build the site themselves and edit the docs
then either send us a patch or fork on github and send us a link to
the commit so we can pull it etc.

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

jstrachan

Re: helping out with the Web site

In reply to this post by dkulp@apache.org

On 10 November 2010 14:51, Daniel Kulp <[hidden email]> wrote:

> On Wednesday 10 November 2010 9:43:13 am Guillaume Nodet wrote:
>> On Wed, Nov 10, 2010 at 14:40, Hadrian Zbarcea <[hidden email]> wrote:
>> > Thanks James,
>> >
>> > You have to comment out the dependency on scalate-test in the pom for
>> > this to work (otherwise you get a "Failed to resolve artifact").
>> >
>> > That aside, one of the important requirements I believe is not to raise
>> > the barrier to entry for those who want to contribute documentation.
>> > Today, one only needs to have a icla signed at apache and edit the wiki
>> > in place.
>>
>> This can be done by submitting a patch attached to Jira.
>
> Which is still a fairly high barrier.
>
> For CXF, we recently got a volunteer
> that has been doing a WONDERFUL job cleaning up various pages on the website.
> That individual has dived right in and started working on thing.
> He's also
> logged some JIRA issues about updating javadoc and warnings and such, but I'm
> having problems working with him to get patches created. For some people,
> working with something like svn or git or even maven is a challenge. It is
> more stuff to install (everyone has a browser installed) and learn.
>
> For most of the people on this list, it ISN'T a big deal. We deal with svn
> and mvn every day. For others, it could be.

Given 99% of all our documentation and web content is developed by
committers or folks who are capable of editing text files and using
git/svn, I'd rather use a system that helps the 99% be more effective.

Maybe you should just help out this one CXF person & show them how to
fork & commit to github (its very easy), then you can easily pull
their commits from there?

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

hadrian

Re: helping out with the Web site

In reply to this post by jstrachan

That is true, but you can see your changes in the wiki right away.

I love the idea of having the docs version controlled, I understand all the benefits. I am also convinced losing the ability to edit in place is a major community issue. Can we have both? We want to make it as easy as possible for people to contribute. Documentation, as shown by the survey, is the #1 issue.

Hadrian

On Nov 10, 2010, at 9:46 AM, James Strachan wrote:

> On 10 November 2010 13:40, Hadrian Zbarcea <[hidden email]> wrote:
>> Thanks James,
>>
>> You have to comment out the dependency on scalate-test in the pom for this to work (otherwise you get a "Failed to resolve artifact").
>>
>> That aside, one of the important requirements I believe is not to raise the barrier to entry for those who want to contribute documentation. Today, one only needs to have a icla signed at apache and edit the wiki in place. How is this solved?
>
> Anyone can submit a patch using the traditional SVN mechanism just
> like for patches to code or build files - or by forking the Camel
> repository at Github.com, editing the entire website there and pushing
> the change back to us. The benefit is folks can now do things like
> grep & search/replace to fix up bad links or whatever.
>
> In either case, whether folks are committers or not, whether they use
> our svn checkout or a git clone, folks get to edit the wiki files and
> actually see what the website is really going to look like before they
> commit/send a patch. Currently the only way to see how the site will
> look after a documentation change is to make the change, then hope
> that in a few hours AutoExport will re-render the page and the Apache
> web cache will eventually refresh. If includes or navigation is
> changed you usually have to wait for an administrator to run
> AutoExport on the entire site...
>
>
> --
> James
> -------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: jstrachan
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration

Claus Ibsen-2

Re: helping out with the Web site

On Wed, Nov 10, 2010 at 4:00 PM, Hadrian Zbarcea <[hidden email]> wrote:
> That is true, but you can see your changes in the wiki right away.
>
> I love the idea of having the docs version controlled, I understand all the benefits. I am also convinced losing the ability to edit in place is a major community issue. Can we have both? We want to make it as easy as possible for people to contribute. Documentation, as shown by the survey, is the #1 issue.
>

I actually don't think we have had many wiki comments about
suggestions for changes on the wiki documentation at Apache Camel.
In my time I would guess its less than 10-20 comments I have seen for
that, in 3 years.

On the other hand if people could send a documentation patch I would
assume we would have far more patches submitted to us, than the
current number of comments we get on wiki.

And then for people to actually be able to edit the wiki page they
have to sign up for the ICLA which takes a fair bit of time and for
some people just scare them off.

So I suggest out first goal is the transition to have documentation in SVN.
Then later we can work on a live web site for the people who may want
to try editing from the web browser. But again if some infastracture
software in the future can do this automatic, eg as James talks about
they work on github. Or if Atlassian is working on some software for
that as well, we can use at Apache.

> Hadrian
>
>
> On Nov 10, 2010, at 9:46 AM, James Strachan wrote:
>
>> On 10 November 2010 13:40, Hadrian Zbarcea <[hidden email]> wrote:
>>> Thanks James,
>>>
>>> You have to comment out the dependency on scalate-test in the pom for this to work (otherwise you get a "Failed to resolve artifact").
>>>
>>> That aside, one of the important requirements I believe is not to raise the barrier to entry for those who want to contribute documentation. Today, one only needs to have a icla signed at apache and edit the wiki in place. How is this solved?
>>
>> Anyone can submit a patch using the traditional SVN mechanism just
>> like for patches to code or build files - or by forking the Camel
>> repository at Github.com, editing the entire website there and pushing
>> the change back to us. The benefit is folks can now do things like
>> grep & search/replace to fix up bad links or whatever.
>>
>> In either case, whether folks are committers or not, whether they use
>> our svn checkout or a git clone, folks get to edit the wiki files and
>> actually see what the website is really going to look like before they
>> commit/send a patch. Currently the only way to see how the site will
>> look after a documentation change is to make the change, then hope
>> that in a few hours AutoExport will re-render the page and the Apache
>> web cache will eventually refresh. If includes or navigation is
>> changed you usually have to wait for an administrator to run
>> AutoExport on the entire site...
>>
>>
>> --
>> James
>> -------
>> FuseSource
>> Email: [hidden email]
>> Web: http://fusesource.com
>> Twitter: jstrachan
>> Blog: http://macstrac.blogspot.com/
>>
>> Open Source Integration
>
>

--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

dkulp@apache.org

Re: helping out with the Web site

In reply to this post by jstrachan

On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:

> On 10 November 2010 14:51, Daniel Kulp <[hidden email]> wrote:
> >
> > For most of the people on this list, it ISN'T a big deal. We deal with
> > svn and mvn every day. For others, it could be.
>
> Given 99% of all our documentation and web content is developed by
> committers or folks who are capable of editing text files and using
> git/svn, I'd rather use a system that helps the 99% be more effective.
>
> Maybe you should just help out this one CXF person & show them how to
> fork & commit to github (its very easy), then you can easily pull
> their commits from there?

Umm.. no. Pulling branches from github is NOT, at this point, an acceptable
way of getting content into an Apache product. They would still need to
create a patch and attach it to JIRA with the "grant" checkbox checked.

--
Daniel Kulp
[hidden email]
http://dankulp.com/blog

jstrachan

Re: helping out with the Web site

In reply to this post by hadrian

On 10 November 2010 15:00, Hadrian Zbarcea <[hidden email]> wrote:
> That is true, but you can see your changes in the wiki right away.
>
> I love the idea of having the docs version controlled, I understand all the benefits. I am also convinced losing the ability to edit in place is a major community issue.

"major community issue" is completely over the top IMHO.

If it really is such an issue, maybe we should switch off subversion
and put our source code on confluence too? We might get more
contributions from people who can't use source control....

> Documentation, as shown by the survey, is the #1 issue.

and since we've had it for 3-4 years already, keeping Confluence is
going to improve the documentation how?

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration

jstrachan

Re: helping out with the Web site

In reply to this post by dkulp@apache.org

On 10 November 2010 15:15, Daniel Kulp <[hidden email]> wrote:

> On Wednesday 10 November 2010 9:59:11 am James Strachan wrote:
>> On 10 November 2010 14:51, Daniel Kulp <[hidden email]> wrote:
>> >
>> > For most of the people on this list, it ISN'T a big deal. We deal with
>> > svn and mvn every day. For others, it could be.
>>
>> Given 99% of all our documentation and web content is developed by
>> committers or folks who are capable of editing text files and using
>> git/svn, I'd rather use a system that helps the 99% be more effective.
>>
>> Maybe you should just help out this one CXF person & show them how to
>> fork & commit to github (its very easy), then you can easily pull
>> their commits from there?
>
> Umm.. no. Pulling branches from github is NOT, at this point, an acceptable
> way of getting content into an Apache product. They would still need to
> create a patch and attach it to JIRA with the "grant" checkbox checked.

Whatever happens folks have to raise a JIRA and click the "grant" checkbox.

I fail to see why a link to a specific commit (i.e. a link to a number
of patches) is any less suitable than a number of patch files being
attached in place to the JIRA. Got anything specific to back this up
or is it just that we've not done it before?

Patch files are a total PITA for both the person contributing and the
person applying the patch. (They usually break, get out of sync, have
whitespace issues and frequently have the wrong path information in
them & often have problems with new/renamed/deleted files).

If this discussion really is about being a "community issue" and
making it easy for both folks to contribute and for committers to
apply those contributions, I'd rather we figure out this issue of
using links to git commits as an alternative to patch files on JIRAs -
this could make a *massive* difference to both getting contributions
and more effectively applying them IMHO. Helping scm-novices
contribute to documentation (which they've never really done so far on
Camel anyway) seems quite irrelevant in comparison.

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan
Blog: http://macstrac.blogspot.com/

Open Source Integration