How do I contribute to documentation?

Friday 10 February 2006 7:27:16 am

I am very happy to see that eZ systems and community members agree and take the suggestion seriously. I have already written a section on creating a workflow-type extension, and I will put it on the documentation site as soon as it is up.

Leif Arne Storset

Saturday 11 February 2006 1:18:19 am

I just fear that the `almost always` total lock down of the hosting situation that goes along with pubsvn / paulb would limit others on contributing to the site development and maintenance because of their tight security (mod_proxy access limitation, etc). What an eZ network account for something like this? If not ... I'm sure I can provide a host and more open access (in general, like under doc.ezcommunity.net).

What exactly is wrong with pubsvn? Anyone with a good reason get's commit access (personally, I might even say more restrictions wouldn't hurt, so people can't go about messing with other people's projects), no problem there.

I however agree that contributors should get some level of access to admin stuff. And a few will probably have to have ssh to the box as well.

I would personally welcome it if eZ (or possibly one of the other high profile vendors/hosts) was to provide a dedicated machine for that with some sane policy for use. Failing that, it would still be possible to get one (maybe ad supported or some such), decent dedicated servers aren't so coslty anymore (you can get damn good stuff to the tune of 50EUR a month).

Ultimately, I could provide a Vserver (in Switzerland) on a decent machine myself (due to rackspace constraints, a dedicated is not really viable).

Visit http://triligon.org

Saturday 11 February 2006 7:00:29 am

Hi guys and thanks Kristof for the email alert

We can (easily) set up a wiki on pubsvn, along (or with) an integrated "showcase" site for extensions and associated documentation (the showcase being an idea that is already a long time running circles in my head).

But, it will require some coordination and a workflow to make sure the quality is high.

<b>Some technical points/ideas</b>
- The wiki/doc site should be based on eZ publish, otherwise it would be a blow to eZ publish itself, isn't it?
- Since 3.8 feature freeze is on March 1st, and release a bunch of weeks later, we may best start with 3.7, patched and extended to our needs
- Part (like the design) or all of the site should be in svn (except the database of course). Some would have write access then, a small team for maintaining the look and feel and for adding extensions (also for the showcase part). So we have a development version of the site. The real site will be updated after review of the development version.
- We could setup ssh access for a few to backup myself and Kristof for some maintenance tasks (their won't be many)

<b>About the content, workflow</b>
- We should avoid to duplicate the ez.no docs as Allman/Sandro point out and I'm glad the ez.no team is concentrating on the reference part (the most boring to write imho from "past experience")
- Can we agree on a license or should we allow a few (indicated per page) ?
- I would suggest a workflow where pages get some kind of status (draft, reviewed, obsolete) and other attributes which allow for a knowledge-base-like functionality. Let's put object relations to work, so we have a true "knowledge management" tool for the ez community ;-)
- People should be able to file bug reports and comments which should be handled by a core editor team.
- We shouldn't be limited to pages, I've seen a few nice tutorials as movies lately (VisionWT for example)

Let's continue talking ....

--paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Monday 13 February 2006 10:49:20 am

Just an idea for discussion: how about making the ez.no docs trackback-enabled, so that e.g. the community docs can refer to certain pages of the docs?

Could be done with the new extension: http://ez.no/community/contribs/applications/ez_trackback

Sandro Groganz
Chief Knowledge Officer

Monday 13 February 2006 11:56:20 pm

Hi all

I've just read through this thread and am a little confused. The situtation seems to be that
1) The "Documentation" is incomplete and needs work
2) There are several community members that are willing to pitch in and write documentation
3) The current solution seems to be to create a seperate community documenattion project

Is there any reasons that community members can't be given the ability to contribute to the existing documentation?

Whats the point of the Community section of the ez.no site again??

Cheers
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

Monday 06 March 2006 2:00:37 pm

*bump*

What has or will become of all this then now?

//kracker

Member since: 2001.07.13 || http://ezpedia.se7enx.com/

Tuesday 21 March 2006 3:57:02 am

Let's summarize some possibilities:

hosting: pubsvn, kracker, Gabriel

domain name: subdomain of ez.no like pubsvn.ez.no or a seperate domain like doc.ezcommunity.net or ezcommunitydocumentation.org

wiki: using the wiki extension, or using an eZXML attribute + some WYSIWYG editor (OE or one of the free contributions) + related objects ( in this case we can view changes with the new content version diff functionality announced for eZ 3.8, searching for orphan pages = fetching wiki articles that don't have any reverse relations )

edit access: anonymous or login required

candidates to take the lead: ?

@kracker: I still haven't heard what's wrong with pubsvn ;)

@gabriel: can you track down orphan pages with the wiki extension?

independent eZ Publish developer and service provider | http://blog.coomanskristof.be | http://ezpedia.org

Wednesday 22 March 2006 12:50:07 am

Right now I can't track orphan pages, no.

I don't think it would be THAT hard to implement, though (might take somewhat ugly queries though and thus could be slow).

But they aren't ever totally orphan if you decide to list all wiki contents in the wiki folder, anyway.

One could, of course, think about having the wiki somehow generate object relations for CamelCaseLinks...

And yes, the wiki has diff functionality.

Demo install at http://triligon.org/triligon/projects/mywiki/testwiki

Visit http://triligon.org

Wednesday 22 March 2006 2:45:01 am

Discussion of a wiki reminds me of the *original* eZ publish 3 wiki site which was run by the community when there was no documentation from eZ apart from api stuff!

Paul

Tuesday 04 April 2006 8:19:38 pm

<i>@Sandro : Just do it!</i>

Thank you for getting back to the thread :)

<i>@kristof : I still haven't heard what's wrong with pubsvn ;)</i>

*nothing*, I retract my previous comment. my apologies.

I was had a perception of problems accepting alterations of the wiki site's code (improvements) because of a previous impression of pubsvn's tight security (no: ssh?).

Though as I think of this now, storing the entire configuration in svn as a complete installation which is regularly updated from svn via cron could easily address accepting site improvements (not content related) and allow for others to have local copies of the whole thing too?

<i>@kristof : I'm currently working on a site design for a wiki</i>

Neat. Has it been a week, preview image?

<b>@all</b>

All right guys, so is now a good time to start? By putting a copy of eZ publish (3.7 / 3.8?), some of the supporting extensions recommend in the thread so far? To just get started putting together the code, for those who can / will to start building and committing connected functionality to get the show on the road .... while a more cohesive plan is hammered out on paper?

Where would you put it, here? http://pubsvn.ez.no/community/sites/

<b>More Questions while moving forward ...</b>

How would you all start planning out the various aspects of code, content organization, implementation, roles, content review, etc on paper.

1. Who will speak up and add their name to the list of who is ready to commit to contributing feature implementation and integration.
1.1 Who will be able to contribute x,y effort during the start up phase.
1.3 Which would like to outline the (initial) layout of content
1.4 What set of features are must have, nice to have, future improvement, if possible (looking to others for a prioritized todo list) to start with ...

* I would like to help with integration, testing of code building up the wiki rather than take on the role of content outliner / editor (for now :)

//kracker
<i>mirwais - disco science ...</i>

Member since: 2001.07.13 || http://ezpedia.se7enx.com/