Loading...
 
Skip to main content

Themes

Forum List Topic List

 
Thread actions
Print this page
  • Print all pages

    • Editing the Contributors' List

    Posted by cgc0202

    Hi,

    I am interested to make sure that the names in the contributors list really includes only the names of those who contributed significantly to a page, not just a complete listing of those who edited or modified the page.

    This can be done manually in an Article page. What is the best way to do this with a Wiki page?

    The "collaborative style" seems to be a start. The "collaborative style" lists all the names of those who edited a page, or God forbid include even the name of the person who just created the first shell page as primary contributor.

    For more serious undertakings what I wish to do is order the list of contributors to correlate the degree of contribution — e.g., primary author, senior author (usually placed last in scientific papers unless also the primary author), and the others arranged sequentially in between to signify their contribution.

    [For example, I correcteded the spelling of a Tikiwiki page here and I was included in the list. In my own pages, I usually create shell pages, for others to use, and I am placed as the primary contributor. These are examples where the names may be acknowledged as having participated in modifying a page, but in both instances, I do not want my name included in the "List of Authors" of the article.]

    In the current version, I do not see a way of doing this except to "disable" the Contributors List option. However, I do not want to take the "disable" option because I want to acknowledge also those who modified or edited a page — and the best way to do this is to keep the "collaborative style".

    Any suggestions on how to reconcile the above? Or, is there anyway to include the "Manual input of author(s), just like in the "Articles" pages?

    Thanks.

    cgc0202

    Reads: 1636
    Posted by Gary Cunningham-Lee Japan

    > Hi,
    >
    > I am interested to make sure that the names in the contributors list really includes only the names of those who contributed significantly to a page, not just a complete listing of those who edited or modified the page.
    >
    > This can be done manually in an Article page. What is the best way to do this with a Wiki page?

    There's no way to do this for wiki pages, as far as I know.

    > The "collaborative style" seems to be a start. The "collaborative style" lists all the names of those who edited a page, or God forbid include even the name of the person who just created the first shell page as primary contributor.

    It's a judgement call as to how import any particular contribution to a wiki page is. Maybe thinking up the idea for the page itself is a stroke of genius in some situations and should be acknowledged. 😉

    > For more serious undertakings what I wish to do is order the list of contributors to correlate the degree of contribution — e.g., primary author, senior author (usually placed last in scientific papers unless also the primary author), and the others arranged sequentially in between to signify their contribution.

    This would take new coding.

    > ....
    >
    > Any suggestions on how to reconcile the above? Or, is there anyway to include the "Manual input of author(s), just like in the "Articles" pages?

    Yes, hire or persuade a PHP programmer to customize the files.

    -- Gary - zukakakina.comQuestion

         Posted by cgc0202

    Thanks Gary,

    The simpler solution that I could do immediately with what I suggested above is just to use the "Articles" option. But, as we discussed in a thread awhile back lasts year, one limitation of the "Articles" option is the lack of "history", with one single copy vulnerable to malicious attack. Moreover, the "Articles" option does not have many of the features that made me consider tikiwiki in the first place.

    ......................
    > > For more serious undertakings what I wish to do is order the list of contributors to correlate the degree of contribution — e.g., primary author, senior author (usually placed last in scientific papers unless also the primary author), and the others arranged sequentially in between to signify their contribution.
    ......................

    You responded:

    > This would take new coding.

    ......................
    > > Any suggestions on how to reconcile the above? Or, is there anyway to include the "Manual input of author(s), just like in the "Articles" pages?
    ......................

    You responded:

    > Yes, hire or persuade a PHP programmer to customize the files.


    The main reason why I chose Tikiwiki for text and articles (mainly) is the collaborative nature, with permissions option inherent in the wiki format. The redundancy and potential rollback, in case of vandalism is an added and critical bonus.

    However, I decided a long time ago to use different programs for the calendar, the directory, the gallery because I found more advanced and sophisticated programs around. Even the forum of Tikiwiki, many of those who tried the family website that I created and who are more familiar with the phpBB format, find the nested approach of Tikiwiki a bit confusing.

    It will be a nightmare in threads where there are hundreds or thousands of responses. I am sure you know this already. Craiglist is the only big commercial group that I am familiar with that still uses nested forums, for the reason I mentioned. One difference between of the Craigslist forum is that the posting details are actually collapsed, unlike the tikiwiki forum format. In that sense, ithe Craigslist may be easier to follow. In terms of elegance, it does not look good either.

    Hiring a programmer — as you suggested — outside of the decisions makers (i,e,m the core group) of Tikiwiki may be counterproductive. In fact, I recall reading a thread where a programmer drastically revised his copy, I believe of the 1.7x series. His predicament though was when the 1.86 became available and had instituted security patches, the programmers now had to decide whether to stick with his 1.7x program or migrate to the later version and do the same change.

    Now, we are in the 1,92 stable version with the 1.93 to be released later this month???. [And the ipromise of the great feature of a v1.10 talked about in some threads.] I hope you get where I am going.

    The point that I even suggested this here is that I recognize, as realized by the programmer in the story I related above is that any hacking to customize such a bulky program like Tikiwiki is counterproductive unless the changes are adopted by the core group to become part of the future development of Tikiwiki.

    I hope eventually Tikiwiki could catch up with the aforementioned features, but I think that will take some time.

    I read awhile back of a more "nimble TikiWiki", I think it was more as nimble as the software used for mediawiki, except it has the more stringent permissions and the article attribution (i.e., authorship) inherent in related programs like Tikiwiki. However, when I tried to click on the website, it was no longer existent. So, I concluded that the more "portable Tikiwiki" developer just gave up.

    That was unfortunate because a "nimble Tikiwiki" focusing mainly on its "wiki" features as I discussed above is quite powerful on its own — for many applications, including very serious applications.

    I thought I found such "portable wiki" similar to what I found later with the wiki features of Tikiwiki.

    Unfortunately, the guy who developed it thinks of himself more as the gift of God to mankind. I wrote to him, inquiring if there was any Manual for the program so that I could use to learn more about his program.

    He wrote back to me in a condescending tone that if I do not have an advance experience with scripting, I should not even begin to consider using his program. It was all bulll of course, because his only claim to fame, making his program different from the simple mediawiki program — from what I understood then — have of course been adopted by other open-source programs (his was under "Creative Commons" License) like Tikiwiki.

    Anyway, that is my convoluted response to your cryptic response.😀

    Sorry, English is not my native tongue.

    I cannot emphasized too much though how grateful I am how active you are in helping us who are still trying to learn the program — one as complex as tikiwiki.

    cgc0202

    Posted by Gary Cunningham-Lee Japan

    > Thanks Gary,
    >
    > ....
    > The main reason why I chose Tikiwiki for text and articles (mainly) is the collaborative nature, with permissions option inherent in the wiki format. The redundancy and potential rollback, in case of vandalism is an added and critical bonus.
    >
    > However, I decided a long time ago to use different programs for the calendar, the directory, the gallery because I found more advanced and sophisticated programs around. Even the forum of Tikiwiki, many of those who tried the family website that I created and who are more familiar with the phpBB format, find the nested approach of Tikiwiki a bit confusing.

    The posts can also be arranged in a "plain" sequence, not nested. There's a toolbar across the top of the forum posts with "Messages - Style - Sort - Threshold - Find" gadgets. Have you tried the plain view?

    > It will be a nightmare in threads where there are hundreds or thousands of responses. I am sure you know this already.

    Yes, especially on narrow-page designs, it's good to minimize the inset dimension for threaded message display when designing the theme, or else to use the plain display.

    > Hiring a programmer — as you suggested — outside of the decisions makers (i,e,m the core group) of Tikiwiki may be counterproductive. In fact, I recall reading a thread where a programmer drastically revised his copy, I believe of the 1.7x series. His predicament though was when the 1.86 became available and had instituted security patches, the programmers now had to decide whether to stick with his 1.7x program or migrate to the later version and do the same change.

    Right, that's a valid point. But it becomes a question of whether a particular Tiki user wants to wait for the often slow evolution of Tiki features, or go ahead and customize the scripts to meet an immediate need. If the customization is limited to a few files and/or database changes, as with the wiki author code, it wouldn't be hard to update the customized files when the originals are updated, especially if the customizer keeps careful track of what was changed.

    If the majority of Tiki users are satisfied with the existing wiki author indication, then it is unlikely the current method will be changed when there are so many other things that need attention in the view of the majority of Tiki users and developers.

    > Now, we are in the 1,92 stable version with the 1.93 to be released later this month???. [And the ipromise of the great feature of a v1.10 talked about in some threads.] I hope you get where I am going.
    >
    > The point that I even suggested this here is that I recognize, as realized by the programmer in the story I related above is that any hacking to customize such a bulky program like Tikiwiki is counterproductive unless the changes are adopted by the core group to become part of the future development of Tikiwiki.

    If the changes would be valuable for most/all Tiki users, then it does make sense to incorporate them into Tiki itself. This is in fact how Tiki has gained features in the past in some cases. But if relatively few users feel the need for a particular change, then there is a stronger case for independent customizing, or for doing the change in such a way that it can be a Mod (added to the installation separately).

    > I hope eventually Tikiwiki could catch up with the aforementioned features, but I think that will take some time.

    That's the key phrase.

    > ....
    >
    > Anyway, that is my convoluted response to your cryptic response.😀
    >
    > Sorry, English is not my native tongue.

    You handle it well.

    > I cannot emphasized too much though how grateful I am how active you are in helping us who are still trying to learn the program — one as complex as tikiwiki.

    Well, I was once in the same position, and put quite a bit of time into trying things out and so on; I was helped by others and now I'm able to help in return. Also, I have a job where I have a fair amount of free time at the computer, so it's probably easier for me than for others to help out.

    -- Gary - zukakakina.comQuestion

         Posted by cgc0202

    >
    > > It will be a nightmare in threads where there are hundreds or thousands of responses. I am sure you know this already.
    >
    > Yes, especially on narrow-page designs, it's good to minimize the inset dimension for threaded message display when designing the theme, or else to use the plain display.
    >

    Well, one of the reasons why I chose a two-column format is because of the nested forums.


    You are correct of course Gary in regard the plain format. But, because of the format of Tikiwiki, the conversion to a plain format will work only if people "quote" what and who they are responding to. If people don't quote, converting to "plain format" will look nice but readers may not know who is answering whom.

    Once a format has started as a nested format, converting to a plain format for that post is even more confusing (without quoting the post). At least that was my impression I have when I convert to the plain from a nested format, as you suggested.

    I looked at the Admin panel to see if the plain option could be made a default, from the beginning. It should be a control option that is either all or nothing for the whole site — not from thread to thread, as configured now.

    cgc0202


    Posted by Xavier de Pedro Catalan Countries

    Hi cgc0202 and Gary:

    In case you cgc2002 get somebody to code what you're looking for, I'd suggest to use some of the new development we requested and payed a dev. (sylvie, inside core admin group, luckily! 😊:

    http://doc.tikiwiki.org/ContributionsQuestion

    Cheers,

    xavi

         Posted by cgc0202

    > Hi cgc0202 and Gary:
    >
    > In case you cgc2002 get somebody to code what you're looking for, I'd suggest to use some of the new development we requested and payed a dev. (sylvie, inside core admin group, luckily! 😊:
    >
    > http://doc.tikiwiki.org/ContributionsQuestion
    >
    > Cheers,
    >
    > xavi

    Hi xavi,

    I have not been here for a few weeks. I posted my thoughts here because as I responded to Gary, it would be much better if a page is not customized too much, such that it will be difficult to change it again when the next version comes along.

    The other thing is that because of the collaborative focus I wanted the page to have as a direction, it is not a good idea to pay some people while "not paying" others for their contributions. The core groupd at Wikipedia had to grapple with the same issue a few years back because with the strictly voluntary nature of "open source" developement, there are components of the "mediawiki" that they wanted to be developed but were not being done.

    So, I believe one of the leaders among the core developers posed the question about the prudence of hiring (paying) programmers to hasten the development of neglected areas. Many long time contributors (programmers) were passionate in their disagreement to the idea. I do not know what happened after that because the guy who proposed it had some good points too and it looked like since he had as much say, might be leaning towards it anyway.

    Personally, I like the fact that the "mediawiki" software is very lean. Therefore, it does not have the issues associated with the complexity of Tikiwiki. This is understandable because Tikiwiki is also a CMS. But then, there comes a point when a program gets too bloated, just like the case with the Windows. This gave birth to Linux.

    The main reason why I like Tikiwiki over "mediawiki" is the concept of accountability associated with the collaborative environment of a "wiki". The authorship for me, is not so much for vanity but more so people take the responsibility associated with their words — rather than the anarchic anonimity fostered in Wikipedia. I still use wikipedia a lot, as a resource but it will never be considered as a serious source of information unless the "accountability" issue is addressed.

    Honestly, if I can find a simpler "Tikiwiki" with its permissions system to ensure the accountability that I alluded at above, in a collaborative environment, I would in a minute move to such a software. So, if anyone know of such, with the robust support system that prevails here in the Tikiwiki community, I would be very grateful to know.

    cgc0202