PGVWiki talk:Purpose

This page is designed to seek from the PGVWiki community some consensus on a number of issues so that the site can move forward in a common direction. The original content is submitted by Laurie Lewis seeking comments. Please make your comments in relation to each section in the comments area for that section. I would also like to thank Tom for his questions and probings that have me up at 1am typing this because I can't sleep.

Purpose

Laurie's vision

The idea of a wiki came about from a question in the phpGedView Help Forum and has been discussed since that time. A clear consensus by its current users on it's purpose is essential. It is clear that the design of something should come about after it's purpose has been decided. To some extent our design will be limited by our choice of software (Mediawiki) but the software allows quite a bit of flexibility. From my involvement I would like to suggest the following as PGVWiki's purposes:

1. Primary Purpose: PGVWiki is a high quality documentation site related to phpGedView, that is maintained and updated by the user community.
2. Secondary Purpose: The provision of basic genealogical information to assist users of phpGedView, to gain maximum benefit from the software.

--Laurie Lewis 01:23, 8 December 2005 (EST)

Tom's vision

Imagine never having to visit the SourceForge forums again. Imagine a living, growing knowledge base of phpGedView information that is frequented by the phpGedView developers. Imagine clicking on the Discussion tab behind the Installation article, asking why your widget gleaks when you nixit, and having a real person say, "Try the foobar page. I just added information that addresses your question. And your question is a qood one. I added it to the Installation questions page." You can't do it wrong. Anything is better than nothing. Just start writing. Imagine several ideas of site organization co-existing and thriving with their respective champions--categories, languages, lists, sections (namespaces), help desks, and more, with the successful and useful ones coming to the top, and all glued together by Google and the site search engine.

Success means the whole community adopts this as The PGV support site. Failure means anything less. I personally am willing to help gently guide a relevant, vibrant, growing site into eventual increasing order. But I am not willing to guide an irrelevant site into eventual, gradual completion.

Obstacles to success

I am seriously, but hopefully, tentative about the chance for success as a documentation/help wiki. Many of my concerns are expressed at Wikis Do Not Work for Technical Documentation "Wikis do not work for technical documentation. For technical documentation to be usable it must be clear, complete, correct and current. Wikis fail on all of these points.". We should also take the time to read the wonderfully through and thoughtful Using a Wiki for Documentation and Collaborative Authoring "the greatest success factors for integrating technology into a business include building an understanding of users and removing the barriers to the use of the technology". I will be doing so. Good stuff. Tom Haws 16:11, 24 November 2005 (EST)

Comments

• high quality What does it mean? Orderliness? Vastness? Comprehensiveness? "Complete"ness? Usefulness? Relevance? Unity? Beauty? Consistency? High energy? Structure? Searchability? Elegant prose? Hierarchy? Transparency? Current? Growing? Responsiveness? Aliveness? Correctness? What is success here? What is failure here? Tom Haws 02:23, 8 December 2005 (EST)

Community needs

To meet the need of the user community it should provide the following aspects:-

1. Available in all the languages that phpGedView is available in
2. Be consistent across all languages
3. Provide for the needs of various versions of the software

--Laurie Lewis 01:23, 8 December 2005 (EST)

Comments

• consistency I'm not sure that number 2, language consistency, is that important. In any case, it implies an awful lot of work. Who will do it? It goes to the core of how we intend to succeed. Will this be a cathedral or a bazaar? If a cathedral, then yes, number 2; but if I am the builder it will be quite tiny. If a bazaar, then no. Tom Haws 02:01, 8 December 2005 (EST)

I suppose what I am referring to here is the phpGedView Documentation as once this is done the site should have a lot of visits but not a huge amount of updates I would think. The documents that I think need consistency across the language groups are Administrators Guide, Users Guide, Installation Guide, How to and FAQ's. Also the site procedures/policies/guidelines whatever you want to call them would need to be translated and be the same to ensure a level of consistency. There is still a huge area for open communication in the talk pages that never needs translation. --Laurie Lewis 02:15, 8 December 2005 (EST)

Floating around today I found this site which is probably the closest I have found to what I have been describing. You will notice that the language links are at the top on PGVWiki they will be on the left (version differences). You will also notice that the language in the sidebar does not change - also note name convention on pages and url as you change pages. --Laurie Lewis 16:07, 8 December 2005 (EST)

This link talks about the advantages and disadvantages of seperate language wiki's/projects. --Laurie Lewis 16:39, 8 December 2005 (EST)

Quality Documentation

A quality document is one that provides the best information to the reader both in its content and how it is presented. PGVWiki is about supporting a single software package - phpGedView and therefore is singular in its focus. Quality documentation will need to be consistent across ALL languages. As a community we are not attempting to write numerous books/manuals but to write ONE quality manual that can be translated into numerous languages. The basis of this is founded in the childrens game of "Chinese Whispers" where a story is told to the first child and is passed along the line - the story changes with each telling and the final story is not what was started with. To this end I believe it is essential that there is ONE CORE documentaion language and all other documents are translated from that ONE language. As phpGedView is an English based software product, its website's core language is English and we started PGVWiki in English I suggest that the base language be accepted as English. --Laurie Lewis 01:23, 8 December 2005 (EST)

Site Design

The site may be designed in two ways to support multiple languages.

1. Seperate domains
2. Single domain with translations

The first of these options would create a number of virtual wikis for each language group. Looking at Wikipedia allows you to quickly see this setup. It allows the creation of a number of communities. You will see that the content from one language group to another is not consistent. I believe that this is not in line with the concept of quality documentation for a single software package. Whilst PGVWiki can be configured this way I believe it will be detrimental to the original purpose stated.

The second option is that the core document language remains English and that translations are done for each page. As each page is translated appropriate links are put on the page that show in the left column that the translation has been done and is available in that language. This is not to say that improvements to the documentation can not be started in other language groups - they can - it just means that the English version must be updated first as it is the template for all other documents. They MUST mirror it to be a successful documentation site I believe. When pages are translated the links on those pages will not point to the English Versions but to the mirrored equivalent of the english page in the appropriate language. Similarly if another language group wanted a page put into the wiki that page would have to be first entered in English and then translated into that language. This has been touched on in current policies placed on the site but some agreement as a community is necessary before further work is done.

This will have some impact on the navigation of the site but I would suggest it would be minimal. Once links are established in translated documents the movement within those documents should be smooth. It is only when a user selects a menu item on the left of the screen that they will be taken to the "English" page. If that page has been translated the language link will appear and they can select it. Whilst perhaps inconvenient in some ways it is a minimal disturbance that I believe must take second place to consitency in the documentation.

After some though I believe that translated pages should be prefixed by their language code (eg Fr/ Es/). In this way translated pages can quickly be found as they will be grouped together by their language code. This would not be achievable if the language code was placed at the end of the page title like it is currently configured for. --Laurie Lewis 01:23, 8 December 2005 (EST)

Comments

I have noticed that in the User's Guide, some of the main menus, such as My Gedview Portal and Charts Menu are not editable. In my mind, they should have a general explanation on the purpose/usage of that section. For example, my addition to the Discussion part of Charts Menu, should be shown when the Charts menu is selected.--Anton 09:15, 8 December 2005 (EST)

All the pages are editable. Those pages simply need a link made to another page. I have done a quick example to show you how you or anyone else could do it with the My GedView Portal area. I kind of agree that an overview would be good, so unless anyone objects lets put them in. I am not sure what you mean by the disucussion part of charts menu. --Laurie Lewis 09:33, 8 December 2005 (EST)

For the convenience of those who are following, could you add some links to the comments above? Thanks. :-) Tom Haws 09:37, 8 December 2005 (EST)

Link added. --Laurie Lewis 09:57, 8 December 2005 (EST)

Just some further information on multiple language wikis that all have their own namespace/domain. Setting this up means that you can not have common users throughout the system. Users will have to register on each system. May not be a problem but for some but it is dividing the community - just for information --Laurie Lewis 22:42, 8 December 2005 (EST)

Community Discussion

Community discussion is essential but the purpose of the wiki is not a chat room. The nature of a wiki must allow for interaction between community members. I believe that discussion within language communities can still take place in the talk pages quite effectively. The results of these discussion will result in changes to documents etc. This would be fine but the changes must first come into the English version and flow out from there - good ideas come from everywhere but to meet the original purpose stated there needs to be a greater degree of control in this wiki than in others (unless of course I have the purpose wrong). Discussion can still take place on user:talk pages as well. --Laurie Lewis 01:23, 8 December 2005 (EST)

Comments

• flow direction I may be wrong, but this feels stifling to me. There are no paychecks and no employee manuals here. How can we get people to do work most effectively? If we take a little bit of the creativity from the work and throw in a bit of tedious translation, what effect does it have? Perhaps we are just depending on 16 dedicated souls to come along and translate/build the site in their respective languages. I just hadn't envisioned it that way. What I had envisioned was getting an inviting "toy" set up, porting all existing text (sourceforge forums, PGV docs, etc.) here, and pointing the community here, to The PGV Knowledge Base, Help Desk, and Tech Support Wiki from now to eternity. And talking together about the vision is important. Thanks, Laurie, for starting this round of soul searching. Tom Haws 02:33, 8 December 2005 (EST)

Protected Pages

Whilst we want an open facilty for people to add information into to achieve consistency as a document I believe that we need to protect a number of pages from general editing. At this time I would suggest those pages that appear on the sidebar menu.

1. Main Page
2. Community portal
3. Help
4. Donations

PGVWIki Logo should be relegated to a community portal linked page. --Laurie Lewis 01:23, 8 December 2005 (EST)

Comments

I guess I represent the Wiki view here, and as such I have to repeat the warning that Protection is harmful. Until and unless there is a demostrated vandalism or edit war problem, there really is no compelling reason to protect any page. That said, I agree that the PGVWiki logo stuff should be moved to the Community portal. And the Main page should be simplified, simplified, simplified. Tom Haws 09:31, 8 December 2005 (EST)

General Comment

Please do not think that I am a control freak from the content of this page. I believe it has all flowed from the original purpose that I have put forward and is only the result of many hours thinking of how to achieve an outcome. Please indicate any other ideas on how we can achieve what will basically started out to be an electronic manual written and maintained by the user community. --Laurie Lewis 01:23, 8 December 2005 (EST)

• Disclaimer: I am a certified freedom freak. I trust to the limits of reason. I believe to a fault. I hope forever. Is a wiki really what we want? I favor a wiki, but I don't know for certain that it can work. We know that the SourceForge forums are deplorable. Perhaps, for example, a phpbb bulletin board to replace the SourceForge bulletin board would really be better; the http://oooforums.org are a sizzling documentation source for OpenOffice.org. What I do know is that I don't personally have the energy and committment required to personally build a documentation site for phpGedView. The best thing I can do is help in setting up the right conditions to foster growth of a useful knowledge base. Tom Haws 02:12, 8 December 2005 (EST)

Comments

I think the wiki is the correct software for this task as it can be a total piece of work (document) - a tangible location/source, that is there for the user. They find the part they are looking for and all the discussion is there. You do not have to go searching for obtuse links and whatever in the forums. The answer is there with relevant discussion on the talk pages about it. Other sites, Textbooks, OpenOfice.org, Wordpress, phpCMS seem to be using a wiki for documentation but with limited muli-language access, though I am obviously searchin for english words. I notice that their community portals are a bit devoid of activity also, but I do not take that as a negative. I don't think it could ever replace the forums that is where direct contact with the developers takes place. It is really a question of what does the community wish to give back to the software designers/other users. No matter what we do the majority of people will always want to read not write we just need to make an environment where they can write if they want to. --Laurie Lewis 09:07, 8 December 2005 (EST)