things to finish up on

Laura Oh
  • Laura Oh
    Laura Oh

    1. sub-projects introduction
    this issue is not resolved yer over more than 3 months.

    now, all of cubrid sub-projects are in action.

    this page  will show information about introduction, what kind of items each project are dealing with, the url of TRAC(development workplace), mailing list it it has, the project leader, download links, and so on. If possible to display recent news, feed, or update information, it would be great.

    purpose of this page is to let users know development is going on. since we don;t have our own issue tracker on, at least I think we need to push this.

    the issue related to

    cubrid tutorials on pages) and wiki pages.
    currently, wiki pages are not being managed that well. the problem is we hava different application on such as media wiki, wordpress, xe, forum. it is hard to find necessary contents because all are spreaded and scattered.

    why don;t make a rule, such as xe page for contents itself, media wiki for only link map, wordpress for link, for instance.
    why don't removed old(not updated) and duplicated contetns between xe page and wiki page, put the exact version on each doc.
    we don't we has a doc list or doc map of what kind of docs users can refer.

    I'm quite sure that all mess will make users and us confused, even more when cubrid 2008 r3.2 comes out. 3.2 version will have a lot of changes on SQL, functions like cubrid r3.0 did. Before that time, docs need to be organized.

    catalin and esen, please take care of this by end of this year.
    if someone has better idea, go for it.

  • Esen Sagynov
    Esen Sagynov

    1) I started to work on CUBRID Projects page. It will be under "About CUBRID" menu as a separate sub-menu CUBRID Projects. The page will have brief description about each item (CUBRID Cluster, CUBRID APIs, CUBRID Tools, CUBRID Apps) which will link to their separate pages. I will do it this week.

    2) I sent Laura an email about my plans on maintaining the CUBRID Docs. Later I will reveal the final decision here.

  • Esen Sagynov
    Esen Sagynov

    Here are my thoughts on the issue where to keep the primary source of CUBRID documentation and why.

    1) First reason to start CUBRID Wiki was to give external users possibility to contribute to extend CUBRID documentation. MediaWiki provides ease of management. Once you learn how to create a page, do redirections, it becomes easy.

    BUT it didn't work out as we planned due to several reasons:

    a) To contribute to CUBRID (or any other project) user should be relatively familiar with the application, know its differences and features. At his stage of CUBRID development we do not have such users who are CUBRID proficient, so we do not have potential users who could contribute

    b) Thus, first users have to learn CUBRID to help us contribute, which again comes to the point of attracting users, which is what we do all these days.

    c) We intended to deliver CUBRID Manuals on Wiki. The problem arose when it required to be maintained. Converting manuals was another issue.

    2) MediaWiki is a good software to have good search rankings. But based on long monitoring of CUBRID GA data, I found out is doing better than Wiki. The reason is is already linked to many external sites, many references drive traffic, which increases its ranking for Google/Yahoo and other search engines. This is why is doing better than Wiki, thought Wiki has good enough ranking, too.

    So, Wiki nowadays needs additional resources to get maintained.

    a) But I think it is more clever to allocate these extra resources to creating contents than on maintaining Wiki.
    b) In addition now has Lucene to index its pages which provides almost instant and high quality search results.
    c) has in general better user-friendly interfaces which gives good impression to visitors. UX is very important for users to decide if this project is serious enough, mature enough, if it is maintained well enough, which highly influence their decision.
    d) Also documentations on are integrated to the site itself. User are free to move around. They clearly see the structure of the site. I added the TOC module (Table of Contents) which makes it even easier to navigate when reading certain tutorial page.

    About users contribution to CUBRID Docs. This step is important but this time is too early to have users contribute to CUBRID. As I explained, we have to teach users first how to use CUBRID, we have attract more users before they get proficient and start creating their own tutorials on how to use CUBRID. These days many developers have their own blogs and sites. So, the main task is to attract users to try CUBRID and make them like it. When they like, they will eventually write a blog article about CUBRID to become one of the first users to write about CUBRID and to have more traffic to their blogs. The would prefer to write on their blog than on our Wiki site. This is something I missed when I was initiating Wiki.

    In conclusion:

    1) I propose to leave Wiki as it is, users still can access them from Google search. We will maintain the NEW contents on Wiki does not require any actions, except for fixing recent security break. I have reported to the Romania team already through issue tracker.

    2) Concerning the old contents on Wiki, don't worry, users are clever enough, because almost all contents there (except PHP, Ruby, Java, Python) are linked either to CUBRID 2.1 or 3.0 manual. Users see that these manuals are a bit outdated. So they will look for the newer one on Actually, when users access they can immediately see/download the latest manuals. So, they will not have any inconvenience or problems with searching.

    Comments are appreciated.