WeRelate talk:Overview committee/June 2016

Jun 2016 topics

Formulate a long term strategy for WR, following the discussion on the watercooler

Arrange a method of collecting and reporting user views from the water cooler and other posts.

Look into methods of attracting more people to do admin tasks and getting current inactive admins back.

Set a schedule for help pages to be rewritten/updated and allocate admins to the tasks. [2 November 2016]

[First 2 comments below reposted from OC talk page ]

I think restricting editing of Help: pages to only, say, Admins would be a significant mistake, at least without further provisions. The help pages are not the best location for documenting Admin-approved policy, as help page should focus on being helpful to users and so should include suggestions, hints, typical solutions, and such, none of which are typically policy. The Help: pages are currently rather poor, and excluding most of the community from editing them would much reduce the potential for improving them. --robert.shaw 21:00, 29 October 2016 (UTC)

Help pages should be where people go to find out how to do things, so what better place to put policy about what goes in each field, how to format it, what's required and/or expected during the data entry process? They're currently poor because there has been no central guidance or design, and even when there, they're not trusted. Further, restricting their installation does not restrict people from being commissioned, or volunteering, to write help pages. But hopefully it might be done with some direction at the beginning, some review before installation, and some hint of authority due to having a formal update process. Not to mention integrating various "?" links or other help popups with the appropriate Help page. --Jrich 22:43, 29 October 2016 (UTC)

Updating the Help pages is still a priority and maintaining consistency is recognized as being important. I agree with most of the points above and do not think they have to be mutually exclusive. A combined approach could work. For example, on a Help page, when there is an agreed upon requirement in place, the respective text could be presented in two parts:

1. a brief, clear and read-only statement of the requirement, with a link to a fuller explanation of how the requirement was set and why it is necessary
2. an editable section on how the user can meet the requirement to include standards, tips, examples, etc. as provided by the community

Would a solution like this be acceptable to you? --cos1776 17:28, 30 October 2016 (UTC)

I see no reason to create new or different rules for editing Help - any more than doing so for any other sort of page. What's needed is a sufficiently engaged oversight/overview committee, to make sure that Help edits are reviewed to make sure things aren't heading off the reservation.

Beyond that, folks interested in experimenting with practices need to be ENCOURAGED to do so - in consultation with the oversight committee. That means writing help pages to describe and rationalize modified practice. An engaged oversight committee needs to patiently monitor such efforts and recognize when they are sufficiently ripe to present to the wider WR community for discussion and/or adoption as a best practice.

Absent an engaged oversight committee - changing rules for how Help pages are edited means fossilizing what's currently in place. Death by calcification. Trusting the good intentions of the community remains a better choice even then. --jrm03063 00:26, 31 October 2016 (UTC)

That said, it was your response that "I just want to see some conventions adopted - so that we can begin to create code that will standardize date formats" that prompted this whole discussion. Why? Because there is a Help page that discusses date formats and it is based on a universally accepted format, namely GEDCOM. The standard has some leeway, meaning that both 3 or 4 year dates are valid (from an old version of Help:Date Conventions: "The day of the month is allowed to be 1 or 2 digits, and the year is allowed to be 3 or 4 digits long according to the GEDCOM specification"), so using a leading zero is not required nor prohibited by GEDCOM. However, Pkeegstra in 2013 modified the Help page ([1]) to say "Years before 1000 should be expressed with four digits including leading zeroes", and yet, you still posted the referenced item even though the Help page appears to support your position ("my preferred format (leading zero on years before 1000)"). So when one analyzes why, one decides either you think it is wrong that one person can simply edit a Help page and change what is acceptable, or else you are frustrated that people that disagree with you (like DataAnalyst above) can recreate the controversy by simply posting an objection. (I am not expressing an opinion of the issue of leading zeroes either way, I do no work in the era.) Upon analysis, one can only decide that, effectively, the Help page carries no authority. So I think the answer is that the Help page must clearly imply the authority of the governing body of WeRelate. This, to sway people that disagree to go along, and also to convince people that want to help to expend time, effort, and resources to change things in the direction documented on a Help page. Which, to me, says the Help pages need to be a protected namespace.

Regarding "fossilizing" and "calcification": Beside the obvious fact that we are dealing with fossilized facts of people who are dead, and thus, which are not changing (only our understanding of what those facts are is changing), I can deal with fossilized software. In fact, I learn how to work more efficiently the longer it doesn't change. Even trivial little changes like the recent layout changes to the source citations cause problems because it is no longer 1 tab from source title field to page number field and 5 tabs from page number field to source text. (Hopefully I caught and fixed all those citations where I started to enter things in the wrong place.) And while fossilized software has some benefits, using fossilized sources only recreates old myths long put to bed by more modern sources. The value of this website is the data, not the software. Experimentation by individuals only creates inconsistency in data presentation, especially as it is likely to make those change to mere dozens of page out of the millions that already exist on this site. What is needed is a process for change, so new ideas can be incorporated, but it must be orderly and community-wide, and consider all opinions and best practices, and not the whim of one person. Anarchy is not a good basis for collaboration. --Jrich 02:52, 2 November 2016 (UTC)

I think we can compromise and satisfy both viewpoints. I recommend that each Help Page be protected and it's associated Talk Page be universally editable (if possible). Is that a do-able solution? --BobC 04:37, 2 November 2016 (UTC)

That's not compromise. That's surrender. The site doesn't have enough active editors as it stands. That's true for pages of all kinds - and the worst possible idea is to impose restrictions. The question of protecting and asking permission - versus leaving open, risking a bad edit, and asking forgiveness was long ago arbitrated for all pages. Dallan's judgement then was that everything being saved and being able to be reverted was protection enough. Revisiting that established wisdom is neither necessary nor wise. --jrm03063 18:49, 2 November 2016 (UTC)

Date standards confirming policy on leading zero's before year 1000 and in day dates, also month format 3 letters or in full. Perhaps bot to correct data on page save. [30 October 2016]

[21 June 2016] I don't know if you have met and made decisions already, but I would beg you please, please, please NOT to adopt a standard of leading zeros in either years (before 1000) or days. This is NOT how people normally write years or days (except when using a dd/mm/yyyy or mm/dd/yyyy format). I am a computer professional, but even I don't want to be faced with a date format that is overly "computerized" in appearance - it is very off-putting, and I think would detract from the look-and-feel of the site.

If there is a need for reports/bots to sort or compare dates, then translate the dates to a format that is not displayed (this is usually a single number in computer systems) and keep it in the database but do not display it. This is the norm for dates in databases.--DataAnalyst 02:09, 22 June 2016 (UTC)

[3 comments below reposted from OC talk page ]

re: leading zeros for years (only). Jun 2016, Rmg added this phrase to the Help:Style guide, "... years should have four digits so a year before 1000 should have leading zero's [sic] ..." --cos1776 15:12, 27 October 2016 (UTC)

I just want to see some conventions adopted - so that we can begin to create code that will standardize date formats. --jrm03063 19:36, 28 October 2016 (UTC)

What the previous response indicates, perhaps, is that what is needed is unambiguous answers with clearly established authority. I say this since the date format seems to be far better defined that some of the other aspects of the system, and yet we are still talking about it. This, I believe, means that certain parts of the system, like Help pages, and maybe other namespaces, need to be protected from editing by just any user. This, so that it is understood that Help pages represent the policy of WeRelate, and not just the thoughts of the last editor. Further, it would be great to develop software that enforced the agreed upon convention any time a page was saved. --Jrich 02:43, 29 October 2016 (UTC)

[Response moved to "Set a schedule for help pages..." section above]

[Response to internal date format comment]

I think Dallan once indicated that some of the difficulties in sorting dates (an old issue, still pending, related to this discussion) is dealing with before, after and between... So the internal format would have to have a way of representing before 2016, before 30 Oct 2016, after nnn, and between 2000 and 2016, between 5 May 2016 and 30 Oct 2016. I think there are things to do that would work for before and after, and most people would think "before nnn" should sort prior to nnn but after (nnn-1), but how to sort "between" is not so clear. Does it sort as if it was before the first date, or after the last date, or at the midpoint?

Just as a side note I think the shift to Gregorian calendar would probably be easily handled by most internal formats, because it skipped days, so no date was used twice. But conversion between the internal format and the display format might depend on the location since the various locations switched at different times. But I wonder if it could get messy if editing changed the location?

As far as leading zeros or capitalization, I don't believe GEDCOM cares about either, so a choice of either is largely a matter of personal preference. People would presumably get used to which ever format was used, if software converted all dates to a consistent format upon saving the page. However, if they see pages with both styles, they will assume it doesn't matter and use whichever they prefer. --Jrich 17:36, 30 October 2016 (UTC)

Future topics or concerns you would like to see addressed