Comments

Although not a requirement at this time, not being able to back up discussions is a problem.

So far as I know it is not possible to move or copy posts, with the result that topics are lost far from their most appropriate pages - which may not be the page they started on.

And pages get lost - Search seems to deluge me with results.

We've long said that when someone arrives at the wiki home page, it should be obvious, either by main wiki navigation, or by the design of that home page, who we are, how to join and how to contribute to the effort. BUT, reference to "effort' is sort of a ringer, as a wiki without project management focus is, err... a "wiki," which is a point I think Adrian made a while back.

The DTO group envisions there will be both actively administered/managed project teams and less formal working groups. The management of projects will involve more than "moderators," as those projects, not unlike the DTO itself, are expected to produce a result--not just host discussions (not that hosted discussions are unimportant).

The DTO group has a purpose and scope written into the draft bylaws. A bit of a clip follows (quoting):

The scope of NEWORGs work encompasses all aspects of technical standards and guidelines used to manage information in genealogy and family history:

The scope of NEWORGs work encompasses all aspects of technical standards and guidelines used to manage information in genealogy and family history:
(a) Identify existing technical, scientific data practices or emerging trends in international genealogy and family history that require standardization.
(b) Prepare new international standards and guidelines.
(c) Publish and disseminate standards and guidelines
(d) Provide education and support to encourage adoption and use of the published standards.
(e) Review, modify, reaffirm, or terminate existing standards or guidelines.

There are a few more items in that list, but a logical progression is hopefully obvious above. Perhaps it goes without saying, but items (a) and (b) are not the same thing. Item a falls in that "what is the problem"/"what is the requirement" zone, and item (b) is about solutions. I'm not sure a "wiki" alone can do a very good job of keeping ideas/work/and discussions about those two items separated, but I'll throw that in the shoe box about "requirements."

Most of the postings to the wiki are in English, and I'd like to add an ESL (English as a second language) dynamic to the organizational/purpose statement, just above and relate that also to Adrian's comment, also above.

While most browsers come with translation options, English is my native language, and I have a hard time "summarizing" some of the discussion threads when we create different reference lists.

So, another requirement is that the organization of the wiki be conducive to the participation by the global community.

Another requirement is that the navigation bar should preferably not change frequently, it should be independent of the current work and the need for hot topics to get attention.

An issue with new topics being raised is that it is not only a wiki issue, it is also an organizational issue if we are expected to work on that topic - we can not jump from topic to topic just because someone comes along with a new topic. So some pages will need to be backed by procedures. If we are not expected to work on it, but if someone just want to bring something to our attention, that could probably be solved on the wiki, only.

Just a few bits for now ...

Amen to this thread.

In over a year of BetterGEDCOM, I think everything has been discussed at least a half a dozen times.

I promised two meetings ago to modify the Requirements Catalog for the format BetterGEDCOM should be to include some of the options and links to the discussions.

Even that is a formidable task as simply looking up XML in the search box gives 461 results!!!!

This is like having 461 pieces of evidence in a box for your genealogy, but still going out and looking for more without even bothering to figure out if you've already got enough!

I no longer know what the answer is here. Hopefully someone can figure out something.

But I am encouraged that many people are working on producing something tangible that BetterGEDCOM can work with and expand on. Please keep this up!

Louis

Yeah, that is a tough one Louis.

In the area of the Navigation bar, I had hoped to see a hierarchical set of titles. I know there are technical issues there but imagine a set of high-level topics, each with sub-topics for the various issues being addressed under it. This would keep more of the content on the 'Pages' rather than multiple discussion threads which is good for backups.

If the main page for each topic also enumerated the associated requirements then we no longer need a central requirements table that continually has to be updated with entries and links to disconnected pages.

Now, on to your main subject...

Suppose those top-level pages also enumerated links to "relevant" prior discussion threads. That is, ones deemed to be of sufficient interest and relevance to that subject. [I know Pages like Neil's Personal Names one, and others, already do this]. The point being that not all the older threads will be relevant any more. Starting afresh with a better-defined set of requirements gives us a chance to only link to stuff we still want to cite.

Tony

Tony,

Unfortunately, we have started "fresh" twice before, and effectively lost the earlier discussions.

The last time we did so, we already had the Requirements Catalog
I don't see that we did that much better on that restart.

Louis

During the DTO work on the bylaws, we found some unmet needs related to collaborative documents. Posting some findings of that discussion here. BTW, we never did determine an ideal solution.

1. During collaborative GTM sessions, it worked very well to have the document on GoogleDocs, where multiple persons could be editing the document at the same time. With 5-7 persons in the meeting, we could find and make a decision on say a particular term, and one person could make changes to other sections of the document for that same term. This allowed the group to move on to another topic while the changes were being separately implemented.

2. Google Docs doesn't support for "track changes" beyond providing you the date and named party to the last edit. This meant folks began adding their own "markers" (picture a rainbow document), but there was know way to know which of those marked items had been edited since the last visit.

We compared the work on MediaWiki, TikiWiki and Wikispaces, to see which did a better job of reporting about changes. Tikiwiki and MediaWiki allow for a "document compare" but there were no other markers about the changes. Wikispaces "history" pages actually were superior for this purpose, as each deletion or addition is clearly marked.

A few of us also learn how to use the "Save with Changes" feature on Wikispaces. Try it! We used this "save with changes" feature to note minor edits or notice the reason for a major change.

3. The downside of the wiki is really for collaborating comes when two folks, by chance, are trying to edit the same document. With at least Wikispaces, there is always a winner and a lose in that circumstance.

4. Not all wiki's have the kind of discussion feature that we find on Wikispaces. We haven't yet explored all the features available from Media Wiki plugins, though.

5. There are definitely differences between the wikis. MediaWiki creates a very nice table of contents for each page, but MediaWiki is not quite so "what you see is what you get" as wikispaces. TikiWiki builds related features into it's functionality.

Thanks Gene. Have you seen this table: http://en.wikipedia.org/wiki/Comparison_of_wiki_software

Tony

Hi Tony,

TYTY

I had looked at that table before, and also did some research wrt user reviews. Robert did the major work with MediaWiki and TikiWiki, and put together quite a presentation.