From Fedora Project Wiki

 
Line 23: Line 23:
All edits eventually get committed to the VCS. This might help in several ways:
All edits eventually get committed to the VCS. This might help in several ways:


* It helps in continuous evaluation of Beacon as a rich text editor for
* It helps in continuous evaluation of Beacon as a rich text editor for Docbook. I believe this is very important.
Docbook. I believe this is very important.
* Gives us a platform that can be later integrated into any CMS that is chosen for the Fedora Project website.
* Gives us a platform that can be later integrated into any CMS that is chosen
for the Fedora Project website.


Point 1 is something that I really stress upon. We can have Beacon as an
Point 1 is something that I really stress upon. We can have Beacon as an

Latest revision as of 10:50, 28 May 2010

Make generic for any CMS?

Let's make sure the Docs Team is still going to use Zikula for their CMS. It's probably worth making this idea generic for whichever CMS Docs is going to use. If the Docs Team can't make a commitment in time, we'll have to make our best guess of what works for the future.

--Quaid 23:11, 2 May 2010 (UTC)


Sorry for the delayed reply on this. I had planned to discuss it with doc team first and officially announce the project on the mailing list there after. But since this has kicked off I'll try to explain it here too.

What I had assumed was that the web app will eventually be shifted to Zikula and a Beacon plugin could simplify things by making a wiki like setup. But after you mentioning that Zikula might not be final, there could be another way of approaching this which I shall try to describe now.

I have seen a lot of time is being wasted in developing a web app for Beacon. I suppose Beacon should _not_ be a web application any more and should just be a Javascript Library which can be added into any web application.

I think what we might need is an online editing tool for editing documentation with a Wiki like setup and linked to the documentation version control system. All edits eventually get committed to the VCS. This might help in several ways:

  • It helps in continuous evaluation of Beacon as a rich text editor for Docbook. I believe this is very important.
  • Gives us a platform that can be later integrated into any CMS that is chosen for the Fedora Project website.

Point 1 is something that I really stress upon. We can have Beacon as an optional beta editor on the wiki site which any user can opt to use. Its alternative will be a plain XML editor with syntax highlighting and auto indent (there are several great options out there). This will help us in having a Docbook based wiki that is immediately usable and allows the doc team to edit stuff from anywhere. Meanwhile Beacon can be continuously developed and integrated with valuable feedback from users. IMO this is really needed to get Beacon into mainstream. Even something like TinyMCE isn't really loved because it cannot generate beautiful output all the time. Beacon has to break that barrier.

Now, the entire Wiki setup is something that I would like a student to do and can be continued from the work done over GSoC 2009.

What we have at the moment:

  • FAS integration
  • Basic Revisions

We need to improve this with a permissions system and more wiki like features such as "Edit This" links and the likes. Details are something that can be left for the student to figure out with estimates on whether this is feasible over the summer. Also keep in mind that the documentation needs to be browsable just like any other Wiki site.

While the student works on this web application, I'll personally work on the core Beacon logic to make it further usable and convert it into a Javascript library. Since I am not a student I'll be doing it on my own this summer (got some free time off from work) while collaborating with the student. The student will also need a mentor and we have Satya for guidance.

I hope this is not sounding too ambitious as I have made several assumptions here. I do think this might be a good way to provide universal access to documentation editing and get community involved in the process.

--N9986 10:47, 28 May 2010 (UTC)