[This page is under construction. Over the next week I will incorporate the ideas in the discussions]

To enable more people to contribute in meaningful and effective ways to BetterGEDCOM, the following rules and guidelines should be followed when contributing to the BetterGEDCOM Wiki:

These rules are the general guidelines for the entire Wiki. Specific sections of the Wiki may have additional rules that further clarify the process for that section.

See also the wiki page-Proposal for BetterGEDCOM to C.A.R.E

Moderators

The BetterGEDCOM Wiki has several moderators who moderate over various sections. The responsibility of a moderator is to ensure that all rules are followed in their respective sections.

Courtesy

When participating in BetterGEDCOM, courtesy for others should always be a top priority.

Page Types

There are two types of pages on the BetterGEDCOM Wiki: official and non-official pages. Official pages represent content adopted by the BetterGEDCOM community. Content on official pages must be approved by the community using the "adoption" process outlined below. Official pages are tagged with the “Official” tag. Non-official pages can be started by any community member and do not have any restrictions on content other than relevance to BetterGEDCOM. There is no formal adoption process for modifying content and posting discussions on non-official pages.

Official Page Content Adoption Process

Editing Official Pages

Anyone is free to make small changes to official pages such as correcting grammatical errors or minor rewording for better clarification. Fundamental changes must go through the approval process as specified in the “Discussions” section below to ensure community consensus.

Discussions

Each page has a "Discussion" tab where community members can discuss the content of the page. On official pages there are 3 types of discussions: questions/comments, proposals and votes. Proposals are focused discussions that debate specific content for inclusion/modification of the respective pages. Votes indicate each participating community member's vote on a specific proposal discussion. All other discussions are normal question/comment type discussions relating to the page.

Proposal

Proposal discussions start with a community member presenting exact content to add to or change the respective page. The subject of the discussion must start with “PROPOSAL:”. Discussion and debate between community members then starts with each post remaining on-topic to the original proposal. Moderators are responsible for keeping the debate on-topic. Although not required, when an opposing argument is made, counter content should be presented that corrects the debated weakness of the proposed content. The ultimate result of the proposal after adequate debate is the adoption of content into the page or postponement of the discussion because it becomes clear that a different issue must be solved first in order to adequately address the proposed content.

Vote

Once it becomes clear from the discussion that community members have come to a consensus on one or more variations on the original proposed content, or postponement is in order, and all participants have had an opportunity to voice their opinion, the moderator or other community member motions for a vote. If a second member seconds the motion, a new discussion thread is started with the exact same subject except PROPOSAL is replaced with VOTE. A link to this new VOTE discussion is added to the PROPOSAL discussion. Once a vote is initiated all debate on the original proposal discussion is ended. The initial post for the VOTE discussion re-states the exact content incorporating any changes that came about by the debate. If multiple variations exist they are enumerated. Voting is now open. A voting discussion cannot propose changes. Community members simply choose the option they like the best by replying to the discussion with their preference. After a fixed time period (1 week), or it is clear that all community members who contributed to the proposal discussion (and thus have interest in this particular decision) have posted their vote and a minimum period of 48 hours has elapsed [discussion], the winning proposal (by simple majority) is accepted and put into the actual page and the vote is closed.

Community members are not required to vote, however, only community members who have identified themselves on the "Who are we?" page are permitted to vote.[discussion] However, to keep the decision process as rapid as possible, if all members who contributed to the proposal discussion have cast their vote and a minimum period of 48 hours has elapsed [discussion], the vote is closed. Also, if the time period for the vote expires, all votes are counted and the vote is closed. If a community member has an opinion, but is not actively debating the issue, he/she can insure they do not miss the vote by posting at least once to the proposal discussion. This can be as simple as posting "I want to vote on this". This ensures the vote is not closed without their vote unless he/she misses the fixed time period.

If a community member later takes issue with the content, and that issue was not already discussed and debated in the proposal discussion, that member can start the process over with a new PROPOSAL discussion.

PROPOSAL and VOTE Keywords

The purpose of PROPOSAL and VOTE keywords in the discussion subject is to give community members an easy way to quickly identify and search discussions that effect the official pages of the project. As more people join the community, the volume of discussions will continue to increase such that most community members will not have time to follow all the discussions. When that happens, these identifying keywords will become critical.

Creating an Official Page

An official page originally starts off as a non-official page. A community member or group of community members collaborate until the page is ready. A proposal discussion is started that proposes that the objective of the page warrants an official page and that the subject page be adopted as the official first draft. The debate and discussion in this proposal centers on whether the objective of the page warrants an official page and whether the page should be adopted as the first draft. Discussion does not center on the specific content of the page. Once the proposal is approved and the page becomes the first draft of the page, community members can then propose changes and additions to the page as normal addressing their concerns on specific content.

Comments

mmartineau 2011-04-30T21:10:31-07:00

PROPOSAL: Adopt BetterGedcom Rules and Guidelines

I propose we adopt the BetterGedcom Rules and Guidelines page as an official page. The content and purpose of the page will inform new community members how to contribute to the BetterGedcom project.

AdrianB38 2011-05-01T04:14:45-07:00

Seems eminently sensible to me.

Re the voting on proposals, especially "if all members who contributed to the proposal discussion have cast their vote, the vote is closed"

In essence this seems a sensible way forward to determine an informed and useful voting constituency. For the sake of form, I would suggest a minimum period of 48h, otherwise it is possible to propose and vote in a perversely short period, resulting in only a few comments and so only a few votes, before the rest of the world has had time to think. So "if all members who contributed to the proposal discussion have cast their vote and a minimum period of 48h has elapsed".

testuser42 2011-05-01T07:04:41-07:00

Mike, thank you for this.
Yes, I agree we need rules to make this "go" somewhere, and these look very good.

The wiki itself is a cool thing, but the discussion part is badly done. It's like a crippled forum software...
But since we've got lots of content here, we better stay and make it work as well as possible.

gthorud 2011-05-01T14:05:23-07:00

Comments on the proposed rules.

I totally agree on the intention.

Re. OFFICIAL pages (and documents). I expect that the most important such pages or documents would (for the time being) be specifications of some functionality that at some stage is supposed to be merged into a complete BG specification. Most standardization processes goes through several voting steps, voting on new versions of documents, so documents could have statuses as “OFFICIAL DRAFT” (the result of one voting round) and “OFFICIAL FINAL SPECIFICATION” when finished (but that would probably apply only to the complete BG spec). All versions must be assigned a version number, as short as possible. Interim versions, identified by a decimal, should contain a change log referring to votes included. The document is frozen once a new integer version number is assigned, and a snapshot is created. The version number should appear in the subject of discussion topics (therefore a short version number).

Official documents should not be required to be a page, it can be an editable document in eg. a word document attached to placeholder page (advanced editing in the wiki is not easy), but a page is preferred. Snapshots of old versions of a page must be archived – se How to on the wiki. Official pages will typically be subordinate to a page organizing the work on the page. It could be considered to have a page for each version, with discussions of that version taking place on that page. When a reasonable number of changes have been agreed, a new version is created. Each page/document has an editor, defaults to the moderator, but minor edits can be done by others as proposed.

Requirements could also be voted on. It is my view that the BG project is unlikely to produce a standard with the current participation, the important things we can do at the moment is to present requirements and develop possible solution(s) for these requirements that are documented in a reader friendly way. At this stage of the work it might be better to allow development of solutions for “any” proposed requirement (within reason), and in the worst case develop alternative solutions – so that the proposals can have a chance to get a proper presentation. In any case the development will require at least one person to do the work, so the development of a solution where there is only one interested party can not expect others to contribute – but proposers are likely to drop out if their areas of interest are not progressed.

Also, it is my view that BG should be “something to grow into for applications”, and it should support requirements for e.g. specific cultures if that does not cause a problem for others. There are advocates of “short term fixes for Gedcom interworking”. If there are requirements for such solutions, the solutions should be tabled. If not, the requirement for such solutions should not be presented as a reason for not developing more long term solutions.

A major problem is “When do we invoke the voting process?” We could easily be bugged down by a voting bureaucracy if every little piece of a technical solution must be voted on. This balancing act should be further investigated. Other organizations try to collect many changes into a new draft version that is expected to have major support, and then vote on the whole document, with “no-voters” expected to present an argument for their vote (not to be discussed while voting) – and even “yes voters” can make comments (this is how ISO voted some years ago, may also now). If voting takes place on bits and pieces in a document, it could be that the whole document as a whole might not have a majority.

If voting shall have any credibility, voting members must be required to identify themselves on the “Who are we” page. I support the proposal to publish the vote of each voter. The list of voters should be published before the vote. It must be possible to explicitly abstain, majority requiring more than 50% of yes and no voters (or should it be >50% of all voters?). It has previously been possible to vote “Yes, I can live with it” –it is unclear to me if that option has any value – the benefits may need some explanation if it is to be retained. If more than two alternatives exsists, and a majority is not achieved, the two alternatives with the most votes should be voted on. Proposals to defer the voting shall be voted upon first – against all other alternatives. A page should contain links to topics currently voted on, on the whole wiki.

Just for the record: In January/February? I proposed that voting rights should be limited to those who had posted at least a small number of times on the wiki during the current or last month. That proposal was short lived. The result was that anyone of the 100+ members on the wiki could vote independent of activity. I do not think that is a good solution.

Re. deadline for voting. I think a week is a good proposal. In most cases I expect the list of voters to be exhausted before that. Also, consider that we are approaching summer and at least I will not be able to work as much on the wiki as currently – when you have 5 months of winter you want to do other things in the summer.

Does the Developer Meeting play any role in this?

mmartineau 2011-05-02T18:12:40-07:00

Based on discussion in today's developer meeting, I motion to postpone decision on this proposal until other options such as CARE are considered.

mmartineau 2011-05-03T18:47:09-07:00

Thanks for the feedback. To enable focused discussion on the points raised and to close this proposal (keeping with the thought that proposals end in decisions), I copied each of the points to its own discussion thread.

AdrianB38 - Minimum period of 48 hours

gthorud - Voting

gthorud - Draft Versions

gthorud - allow development of solutions for “any” proposed requirement

gthorud - short term/long term solutions

mmartineau 2011-04-30T22:51:10-07:00

Why I believe a well defined adoption process is necessary

According to the Goals page, "The Goal of the BetterGEDCOM Project is:
BetterGEDCOM will be a file format for the exchange and long-term storage of genealogical data.
It will be more comprehensive than existing formats and so become the format of choice."

I interpret this to mean BetterGedcom will define a specification for exchanging genealogical data that will replace GEDCOM. Furthermore, this specification will be adopted and used by all genealogy software vendors that want their products to exchange genealogy data.

I have been an active participant in the BetterGedcom wiki for about 4 weeks now. During that time, I have found it difficult to operate because there is no clearly defined way of getting things done. No clearly defined way to move toward the goal. I personally have difficulty working in that kind of environment. I think others may feel the same. It is alarming to me that in the past there have been several people who were active participants and then they stopped contributing. I have found that over the past 30 days, most of the participation comes from just a few people. This does not sound like a community. I want to be part of a community that is well organized and has a clear process for making consistent steps toward its goal. Looking at past discussions I see that lots of ideas have been presented and discussed, and yet the ideas appear to be forgotten. I don't want to commit my time, energy and resources to BetterGedcom if all my efforts in the end are wasted and what I contribute is forgotten.

GEDCOM will die because GEDCOM does not change. If BetterGedcom moves so slowly that it "appears" to not change then it too will die. If it continues at its current pace, another standard will emerge before BetterGedcom. If that happens the ultimate outcome of the effort put into BetterGedcom will be good reference of collected research for those projects that ultimately define the next genealogy standard.

BetterGedcom must recognize that to succeed in its goal to "become the format of choice," it must gain momentum by having a large community actively supporting it. It desperately needs contributions from all sides of the genealogy community including genealogy software vendors who will ultimately adopt BetterGedcom as their "format of choice." Unless there is a clearly defined way for the community to make decisions, adopt ideas and move toward its goal, as the size of the community grows, chaos will reign, progress will slow, people will stop contributing, the community will die and so will BetterGedcom.

Some have asked me my opinion on the E&C model and want to know why I haven't given it. The reason is simple. I feel the future of BetterGedcom is in jeopardy and that my time would be best spent helping to ensure the future of the overall project than to become one more casualty on the BetterGedcom wiki.

The rules and guidelines I have outlined may seem like a lot of "red tape" for an organization with only a half dozen active participants, but I designed them as a way to maintain order when there are 50 participants or more participating. My opinion is just one opinion and I do not have all the answers, but if we have 50 opinions and we give those opinions a way to organize we will truly create a great product and ultimately realize our goal.

mmartineau 2011-05-03T21:31:38-07:00

While putting myself on the "Who are we?" page, I ran across this discussion

louiskessler 2011-05-03T22:43:46-07:00

Yes. Notice the date. That was 5 months ago. It's 5 months later and we're still discussing governance.

We should have had GEDCOM 6.1 out by now. :-(

gthorud 2011-05-04T16:57:23-07:00

I am still of the opinnion that I stated 5 months ago, and that was one of my reasons for working on the Requirements Catalogue.

I used to work in an environment where say 50 people were working full or part time for several years to produce a (big) standard, and where just one no vote would kill the standard, so I have had no expectations about a 6.1 by now.

In a not to distant future I think the next step is to produce some draft specifications that might make it more interesting for people to contribute.

GeneJ 2011-05-05T14:39:10-07:00

We lost people who posted to that discussion, because they didn't think their opinions were welcome.

gthorud 2011-05-01T13:46:38-07:00

Page structure

An issue not covered in the Rules.

As was mentioned in the last Developers meeting there is a need to include something in the guidelines about the page structure – although that can be done later. One particular problem is: Where to add pages discussion a new topic that there is no page for at the moment, and how to make that page visible – we can not add every new topic to the navigation bar on the left side of the wiki. The wiki structure is extremely important for this project, and there are still pages that can be improved in order to improve the overall “public image” of the wiki and ease navigation for new users.
Mike wrote: “GEDCOM will die because GEDCOM does not change. If BetterGedcom moves so slowly that it "appears" to not change then it too will die. If it continues at its current pace, another standard will emerge before BetterGedcom. If that happens the ultimate outcome of the effort put into BetterGedcom will be good reference of collected research for those projects that ultimately define the next genealogy standard.”

I agree with this statement, especially the last sentence is important, although – who knows if another standard will emerge before BG. So, the structure is very important to ensure that ideas are documented in a way that readers can find them, so they do not just drown in a lot of random discussions all over the wiki – the requirements catalog was the first attempt to create some issue independent structure. More structure and “specification like” documents may attract more participation.

I have no concrete proposals about the page structure at the moment, just wanted to flag the issue.

mmartineau 2011-05-03T17:27:58-07:00

I absolutely agree we need to have guidelines on page structure. In fact, as soon as we finish hammering out (maybe at the same time too) the Rules and Guidelines page, I want to start on a draft of "BetterGedcom Wiki Structure" page and eventually propose it be adopted as an official page. From this page we can clearly outline where everything goes and how organizationally everything fits together. It would also gives us a place to discuss how we want the wiki organized.

gthorud 2011-05-01T13:49:28-07:00

Prioritization of work items

There is a need for a way to organize and prioritize the work. We can not work on too many topics at the same time. A suggestion has been made to create timeslots, e.g. a week or two, when one or two selected major topics will be discussed. New topics could wait in a pipeline. At the end of a slot, the topic will have to wait for a new slot. BUT, it will be impossible to enforce this strictly since the activity will depend on the willingness to contribute in the discussions, and it will be destructive to force a newcomers proposal to wait a long time before it is discussed. Also, issues are dependent on other issues. The experience so far is that everyone has favorite topics that we want to discuss all the time, but if a sufficient number of people do not contribute on all topics, there will be no end result. The important thing is to create a system where, if your favorite topic is not discussed right now, it does not mean that it will not be discussed.

We need to discuss any rules for the organization and prioritization of work items.

mmartineau 2011-05-03T17:32:54-07:00

I agree. In my opinion, these are some of the fundamental issues that need to be resolved now to enable more efficiency in the future. In my mind it is not resolved until there is an page officially adopted by the community that clearly documents how we operate and how we go about getting things done.

mmartineau 2011-05-03T17:43:35-07:00

Minimum period of 48 hours

Moving this to a new topic from
https://bettergedcom.wikispaces.com/message/view/BetterGedcom+Rules+and+Guidelines/38367372#38370892

AdrianB38 said "For the sake of form, I would suggest a minimum period of 48h, otherwise it is possible to propose and vote in a perversely short period, resulting in only a few comments and so only a few votes, before the rest of the world has had time to think. So "if all members who contributed to the proposal discussion have cast their vote and a minimum period of 48h has elapsed"

mmartineau 2011-05-03T17:44:05-07:00

Sounds good to me. I'll put it in.

GeneJ 2011-05-05T16:20:53-07:00

See the discussion, "http://bettergedcom.wikispaces.com/message/view/BetterGedcom+Rules+and+Guidelines/38511116

gthorud 2011-05-05T16:51:16-07:00

I have previously suggested 7 days, but reconsiddering 72 hours should be sufficient. An issue with avoiding weekends was mentioned in the las Dev meeting. One might considder a longer period if voting on a large document.

GeneJ 2011-05-05T18:10:46-07:00

"One might considder a longer period if voting on a large document."

I always thought it was better to avoid the long document. Things may be too far down the road for that, right.

mmartineau 2011-05-21T08:27:00-07:00

72 hours sounds good to me.

mmartineau 2011-05-03T17:55:47-07:00

Voting

Moving this to a new topic from
https://bettergedcom.wikispaces.com/message/view/BetterGedcom+Rules+and+Guidelines/38367372#38381330

gthorud said "A major problem is “When do we invoke the voting process?” We could easily be bugged down by a voting bureaucracy if every little piece of a technical solution must be voted on. This balancing act should be further investigated. Other organizations try to collect many changes into a new draft version that is expected to have major support, and then vote on the whole document, with “no-voters” expected to present an argument for their vote (not to be discussed while voting) – and even “yes voters” can make comments (this is how ISO voted some years ago, may also now). If voting takes place on bits and pieces in a document, it could be that the whole document as a whole might not have a majority.

If voting shall have any credibility, voting members must be required to identify themselves on the “Who are we” page. I support the proposal to publish the vote of each voter. The list of voters should be published before the vote. It must be possible to explicitly abstain, majority requiring more than 50% of yes and no voters (or should it be >50% of all voters?). It has previously been possible to vote “Yes, I can live with it” –it is unclear to me if that option has any value – the benefits may need some explanation if it is to be retained. If more than two alternatives exsists, and a majority is not achieved, the two alternatives with the most votes should be voted on. Proposals to defer the voting shall be voted upon first – against all other alternatives. A page should contain links to topics currently voted on, on the whole wiki.

Just for the record: In January/February? I proposed that voting rights should be limited to those who had posted at least a small number of times on the wiki during the current or last month. That proposal was short lived. The result was that anyone of the 100+ members on the wiki could vote independent of activity. I do not think that is a good solution.

Re. deadline for voting. I think a week is a good proposal. In most cases I expect the list of voters to be exhausted before that. Also, consider that we are approaching summer and at least I will not be able to work as much on the wiki as currently – when you have 5 months of winter you want to do other things in the summer."

mmartineau 2011-05-03T20:24:38-07:00

"If voting takes place on bits and pieces in a document, it could be that the whole document as a whole might not have a majority."

I think I may agree. We may want to go with your suggestion to make "many changes into a new draft version"

"majority requiring more than 50% of yes and no voters"
I think for now, we keep it simple and go this route.

mmartineau 2011-05-03T20:31:08-07:00

"If more than two alternatives exsists, and a majority is not achieved, the two alternatives with the most votes should be voted on."

Sounds reasonable. I'll try and come up with some specifics to address your points and put them in the main page.

mmartineau 2011-05-03T20:42:33-07:00

"If voting shall have any credibility, voting members must be required to identify themselves on the “Who are we” page."

I agree with this.

mmartineau 2011-05-03T20:48:10-07:00

"I proposed that voting rights should be limited to those who had posted at least a small number of times on the wiki during the current or last month. That proposal was short lived. The result was that anyone of the 100+ members on the wiki could vote independent of activity. I do not think that is a good solution."

Can you link to the discussion where a decision was made on this, or was it decided in a meeting? What are everyone's current thoughts on this? My thoughts are, people may not be commenting, but agree with how things are turning out (or they may agree with the opposing arguments being made), so they shouldn't be required to comment to participate in a vote.

gthorud 2011-05-04T16:42:11-07:00

Mike,

I think the discussion took place in a Developers meeting, so there is most likely no record.

My intention was that people had to sameway earn their right to vote, so we would not have 80 inactive wiki memebers that suddely decided they wanted to have a say on some issue. Also, no one could prevent someone from registering 10 times as long as they were anonymous, but that would be more difficult if you had to show some activity.

Also, it could have been the case that people just threw in a vote for fun, not really knowing what they were voting on - being active would have reduced the probability for that. This can in the future, to some extent, be avoided by requiring an argument for a no vote (assuming that in most cases the voting is not started unless we have a feeling that a the proposal will be accepted so you are not required to present an argument for voting yes) - as I have already stated elsewhere.

mmartineau 2011-05-04T22:29:33-07:00

Geir,

I see your point. I think you're right, users need to show some activity so we know they are "real" and have some level of understanding as to what they are voting on.

I'm not sure I like the idea of requiring an argument for a "no" vote. It seems like it would clutter up the vote tallying if you have to wade through arguments against. Plus, if it has come to a vote, it is assumed that all arguments for and against have already been presented and discussed.

gthorud 2011-05-05T16:42:19-07:00

Well, I am not sure I see the problem with tallying, you would just have to read "I vote No because" and stop there. Afterwards you would have an idea why you failed to get a majority, if so. And you might have a chance to sort out any misunderstanding, and make sure people realy knew what they where voting on - but the latter applies to both yeas and no votes. But it is not a big issue for me.

GeneJ 2011-05-06T14:08:51-07:00

In the vote, you might have spaces [y] [n] [c], where c is comment only.

Some folks might choose to comment only

mmartineau 2011-05-03T18:25:03-07:00

Draft Versions

Moving this topic from here
https://bettergedcom.wikispaces.com/message/view/BetterGedcom+Rules+and+Guidelines/38367372#38381330

gthorud said "Re. OFFICIAL pages (and documents). I expect that the most important such pages or documents would (for the time being) be specifications of some functionality that at some stage is supposed to be merged into a complete BG specification. Most standardization processes goes through several voting steps, voting on new versions of documents, so documents could have statuses as “OFFICIAL DRAFT” (the result of one voting round) and “OFFICIAL FINAL SPECIFICATION” when finished (but that would probably apply only to the complete BG spec). All versions must be assigned a version number, as short as possible. Interim versions, identified by a decimal, should contain a change log referring to votes included. The document is frozen once a new integer version number is assigned, and a snapshot is created. The version number should appear in the subject of discussion topics (therefore a short version number)."

mmartineau 2011-05-03T18:26:22-07:00

He also said "Official documents should not be required to be a page, it can be an editable document in eg. a word document attached to placeholder page (advanced editing in the wiki is not easy), but a page is preferred. Snapshots of old versions of a page must be archived – se How to on the wiki. Official pages will typically be subordinate to a page organizing the work on the page. It could be considered to have a page for each version, with discussions of that version taking place on that page. When a reasonable number of changes have been agreed, a new version is created. Each page/document has an editor, defaults to the moderator, but minor edits can be done by others as proposed."

mmartineau 2011-05-03T18:29:36-07:00

allow development of solutions for “any” proposed requirement

Moving discussion from
[https://bettergedcom.wikispaces.com/message/view/BetterGedcom+Rules+and+Guidelines/38367372#38381330]

gthorud said "Requirements could also be voted on. It is my view that the BG project is unlikely to produce a standard with the current participation, the important things we can do at the moment is to present requirements and develop possible solution(s) for these requirements that are documented in a reader friendly way. At this stage of the work it might be better to allow development of solutions for “any” proposed requirement (within reason), and in the worst case develop alternative solutions – so that the proposals can have a chance to get a proper presentation. In any case the development will require at least one person to do the work, so the development of a solution where there is only one interested party can not expect others to contribute – but proposers are likely to drop out if their areas of interest are not progressed."

GeneJ 2011-05-05T16:17:37-07:00

Geir wrote, "It is my view that the BG project is unlikely to produce a standard with the current participation, the important things we can do at the moment is to present requirements and develop possible solution(s) for these requirements that are documented in a reader friendly way."

As always, Geir has said it so well.

We need these materials for ourselves, but if we hope to attract talent, others need to understand (1) how we work and (2) the things on which we are working/why it's important, (3) what it all means.

I'm big on transparency. Folks may not like what you have to say, but if they can't find it or don't understand it, they won't even bother sharing their thoughts.