Update OCAL website text to database

Registered by chovynz on 2010-12-14

I'd like to make a widget that is editable text by Librarians so that they can edit the text OF the website.
At the moment only systemgods can edit a web "page" text.
We already have the functionality in the "edit tag description field" and in the tag list.

I propose that we:
1.) Make a new table for all the website text. This will have fields such as [title] [author] [bodytext] [dateauthored] and others I haven't thought of yet.
2.) Make a new widget to display certain texts on the website so that librarians can edit generic website texts.
3.) Make this widget to be editable for librarians only. The librarian will be able to change the content of those fields, but not the style of the website. I believe this is necessary to be able to make the OCAL a limited "wiki"-like site. For example, if we create a FAQ page, then any Librarian can edit the text, but not the style of the FAQ page. Only systemgods will be able to make a new page, but a librarian will be able to edit and contribute to all generic text on the website.
4.) What this will do is take the content generation burden off the system gods and onto the librarians, where it should be.
5.) Pages that I forsee this will affect, (and why I haven't just started doing this yet ... its a major step forward and I need help and "permission" alongside brainstorming) ABOUT, PARTICIPATION, FAQ (future) LIBRARIANS, DMCA, ALL LIBRARIAN MANUALS, and probably others that I haven't thought of.

Basically what this does, will convert all readable text on the website that is not part of feeds or other widgets, into database stored text that will be shown in the relevant parts.
I presume that there will be an sql query like:
           select * from website_text where title = faq
Then we will display each database text as text. Regular users will see it, but not be able to change the text. Systemgods can see it but not edit (preferrably), giving them the freedom to work on the background coding instead of actual content. Librarians will be able to edit. This relies on toggleable librarian status (for librarians themselves to be able to browse as regular users, instead of in the default librarian.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
chovynz
Definition:
New
Series goal:
None
Implementation:
Implemented
Milestone target:
milestone icon 2.9
Started by
chovynz on 2011-02-15
Completed by
chovynz on 2011-02-15

Related branches

Sprints

Whiteboard

But do OCAL really need such tools?
OCAL main goal is to store and promote free clipart - this is the main data on openclipart.org.
Descriptive pages are necessary, but there shouldn't be many of words I think.
We must have necessary and sufficient amount of good static data (well written) on OCAL, and I really don't see reason to make OCAL wiki-like.

Just my 0.02 kopeck.

-----
Thanks for that thought. I'd like to point out the case in point. Jon wants all data from wiki onto OCAL. Then it needs to be updated to current librarian jobs (the job description is not finished.) The wiki will be shut down at some point. It's far too much work for a handfull of systemgods. Me, Steven Garcia, Brad Philips, and Leonardo I would say are the most active on OCAL itself. Bassel and Jon are busy with Aiki and other projects. Steven is heavily involved in Aiki framework, but not necessarily OCAL (yet). Brad Philips is doing the packages and collections. Leonardo has time, but not experience.

That leaves ... me ... to transfer and update lots of wiki pages. Those ones I mentioned are only the beginning. I need more people helping out, but it's no good for someone else to tell me what needs fixing when they can fix it themselves. If the tools are there, and someone comes along with not much PHP skills, but they are a good proof-reader, I can give them an easy (but time-consuming) job of updating the website text. Then I can focus on the more important job of making tools for librarians. It's efficient time-management. If I do it all myself, I'm not being a team-member nor am I using my time very well, nor am I using the skills of other people very well.

Yes, OCAL's main job is to store and supply clipart. But why stop there? Why not make this a clipart place where you can make requests? where you can give examples? Where you can have 30 librarians checking over the text, instead of one person? Where you can have varied and different roles for the librarian instead of the same thing day in and day out?

The "wiki-like" would only be for librarians. It is not for regular users. But if there are 30 librarians, and 29 are bad at writing, I don't expect them to see grammar mistakes and fix them. I expect them to check the clipart. But that one librarian who is great at writing would love to work on the writing and grammar, I would expect them to do this job.

Basically, I want to move the burden of the easy work from off of the systemgods (OCAL should only have a handful of them ... maybe 5 max?) so that they can do the background coding, and debugging and feature implementation, and librarians should be making the content great. This obviously includes the librarians checking the clipart for copyright status, but I also think it should be the librarians who should be editing the site content itself, or updating the procedure manuals, or help files. You can always make a regular user a librarian, and add more. We could have 1000 of librarians and that would be great! But we should only need a few systemgods. It's not good to have all the work on only a few. At the moment only the systemgods can make a page and edit the text.

It's too much to do. We need more people to become librarians, and do the librarian jobs. Updating the website text is one of those jobs. A Librarian is a support person.
 -chovnyz

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.