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.
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".
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.
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?
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