WeRelate:Request List

This page has been superseded by an updated Roadmap.

Requests for improvements to WeRelate that require work by a developer are presented below.

Voting on the request list has resulted in the following list of priorities (30 Jul 2017). Dallan has estimated that we can get about 10 points worth of effort done by fall. I will ask him to proceed.

Note: The overview has been moved to the bottom of this page.

Cemetery pages only on burial location

Effort: 1 point

Based on suggestion: Cemetery pages only on burial location

Filter the place dropdown list so that cemeteries appear only when editing a Burial or Alt Burial event.

Merge MySource into Source

Based on suggestion: Ability to merge MySource pages with regular sources

This request is being removed from this page because I got my wires crossed about what was being proposed. The original intent is that this would be an admin-only tool. Such a tool is currently under development by a volunteer. This will NOT impact the ability to get other requests completed.--DataAnalyst 20:03, 23 July 2017 (UTC)

Sort by page title

Effort: 4 points

Based on suggestion: Sort by page title

Minimum functionality

1. In the search screen, replace “Sort by page title” with “Sort alphabetically”.
2. Rename the “Title index” browsing facet on the left-hand side of the page to “Page index”.
3. When the user selects “Sort alphabetically”:

   • Person pages are sorted by namespace, surname, given name(s).
   • Person pages are included in the page index (on the left) based on first letter of the surname.
   • Family pages are sorted by namespace, husband’s surname, husband’s given name(s), wife’s surname, wife’s given name(s).
   • Family pages are included in the page index based on first letter of the husband’s surname.
   • All other pages are treated as the currently are: sorted by page title and included in the page index based on first letter of the title after the namespace.

Additional options

To be incorporated or deferred at the developer's discretion.

1. Use the new sort order for results when a user selects “what links here” on any page. (Based on Dallan’s comments about how sorts are handled, this might occur naturally as a result of the making the above change.)
2. When displaying a family page in search results, display full names of each spouse, including prefix, suffix and middle name(s) – e.g., Dr. John Albert Smith Jr. and Dr. Mary Jane Barbara Jones. (Note that this is consistent with how Person pages are displayed.)
3. Allow a user to sort contributions by the new sort order for a specified date. That is, allow the user to sort contributions by date (no time stamp) and then alphabetically, or allow the user to filter the list so that it is restricted to a date or date range and then sort the results alphabetically.

Rejected option

• Due to the system cost of sorting by text fields, no additional sort flexibility will be added.

Filter “What links here”

Effort: 1 point

Based on suggestions: Filter for “What links here” (ability to filter) and Sort template for ‘what links here’ page

Minimum functionality

1. Allow the user to filter results on a “What links here” page by:

   • Selecting a namespace.
   • Selecting to show only watched pages, only unwatched pages or both watched and unwatched pages (like the dropdown on the Search WeRelate page). Default is both watched and unwatched (current functionality).

Comment:

• Wikipedia allows filtering on the “What links here” page – presumably we want the look and feel to be similar. It is not clear if this requires an upgrade to MediaWiki – if so, then an alternate solution, such as inserting a new screen before displaying results, might be required. Solution design is left to Dallan.

Additional options

To be incorporated or deferred at the developer's discretion.

1. Allow the user to select multiple namespaces when filtering a “What links here” page. Note that this might be difficult to do, depending on the solution design.
2. If the filtering is captured in a separate screen before displaying “What links here” results, add a setting in the user Setting function to suppress the display of this separate screen – (i.e., to use current functionality without the ability to filter).

Number of rows for “What links here”

Effort: 0 points (trivial change to settings)

Based on suggestion: Filter for “What links here” (change default number of rows)

Minimum functionality

1. Set the default number of rows to display on a “What links here” page to 500.

Additional options

To be incorporated or deferred at the developer's discretion.

1. In the Settings function, allow the user to set the default number of rows to display on a “What links here” page.

Order facts and events

Effort: 2 points

Based on suggestions: Burials – Order in Facts and Events (ordering of facts and events) and Add a Title (Nobility) Event to Person pages (ordering of title fact type)

Existing functionality

• Facts and events are sorted in date order.
• When a date has only month and year, it sorts before other dates in the same month. When a date has only year, it sorts before other dates in the same year.
• Facts and events without dates are (usually or always) displayed at the end.

Requested functionality

1. Facts and events are sorted in modified date order (see below) even if this means that events are displayed in an impossible order, such as death before birth.

   • Rationale: If, for example, the death date is before the birth date, we want it displayed that way to highlight the fact that one or both of the dates is incorrect.

2. Modified date order: When determining whether one date should be sorted before or after another date, the following rules are applied:

   • If the date is a pair of dates (using qualifiers “Bet/and” or “From/to”), use the first date of the pair.
   • If the date has a qualifier of “Bef” or “To” (without the “From”):

   • If the date is day, month and year, subtract one day from the date.
   • If the date is only month and year, subtract one month from the date.
   • If the date is only year, subtract one year from the date.

   • If the date has a qualifier of “Aft”, “Bet” or “From”

   • If the date is day, month and year, add one day from the date.
   • If the date is only month and year, add one month from the date.
   • If the date is only year, add one year from the date.

   • After adjusting the dates if applicable, consider 2 dates to be equivalent if:

   • They are exactly the same day, month, and year.
   • One date has only month and year and the other date has the same month and year (with or without the day).
   • One date has only year and the other date has the same year (with or without month and/or day).

3. If 2 facts or events have equivalent dates, sort them in the following order:

   • Birth
   • Alt Birth
   • Christening
   • Alt Christening
   • Other person facts/events (not specified in this list) in alpha order
   • Family facts in the following order:

   • Engagement
   • Marriage Banns
   • Marriage Bond
   • Marriage Contract
   • Marriage License
   • Marriage Notice
   • Marriage Settlement
   • Marriage
   • Alt Marriage
   • Census
   • Residence
   • Other
   • Separation
   • Divorce Filing
   • Divorce
   • Annulment

   • Death
   • Alt Death
   • Obituary
   • Funeral
   • Cremation
   • Burial
   • Alt Burial
   • Estate Inventory
   • Probate
   • Estate Settlement

4. The following types of facts without a date are displayed in alphabetical order after all facts and events of other types:

   • Ancestral File Number
   • Caste
   • Cause of Death
   • Citizenship
   • DNA
   • Namesake
   • Nationality
   • Other
   • Physical Description
   • Reference Number
   • Religion
   • Soc Sec No
   • Title (nobility)

5. All other person facts and events without a date are displayed in alphabetical order immediately before Death (or where Death would come in the list if there is no Death event).
6. All other family facts and events without a date are displayed in the order listed above (for family facts), after any facts/events for a prior marriage and before any facts/events for a subsequent marriage.

Exception

1. Display all facts of type Title (nobility) at the end, even if they have dates. If any of them have dates, use the dates to sort them relative to each other, but keep all the titles together.

Reorder source citations

Effort: 2 points

Based on suggestions: Burials – Order of Facts and Events (ability to reorder source citations) and Add Source Citation buttons before and after each Citation ID

Minimum functionality

1. Allow users to reorder source citations manually (in the same way they can reorder marriages).

   • Rationale: Users could reorganize census citations into year order, or could group citations from the same source.

2. Renumber the source citations to match the new order.
3. Ensure that references to source citations anywhere on the page (facts/events, the narrative, sources and notes) are updated to match the new order.

Additional options

To be incorporated or deferred at the developer's discretion.

1. Allow users to reorder notes manually (in the same way they can reorder marriages).
2. Fix the bug where when source citations are removed (manually or through automated consolidation), the references other than in facts/events are not updated accordingly. This is not truly an additional option of the request, but a reminder that the bug exists and should be fixed if this code is opened up for changes.

Format date field

Effort: 3 points

Based on suggestion: Format Date Field

Minimum functionality

1. Automatically format dates on GEDCOM upload or manual edit to conform to the following format:
   • d mmm yyyy or d mmm yyyy/yy (for dual dating), where

   • d is the 1- or 2-digit day (no leading zeros)
   • mmm is the 3-character month abbreviation
   • mmm is all lower case if the month was originally entered as all lower case and is recognized as a month in French or Russian (regardless of whether or not the month name is also an English month)
   • mmm is all lower case if the month is recognized as a month in French or Russian but not in English (e.g., MAI)
   • mmm is mixed case (leading capital) in all other cases
   • yyyy is the 3- or 4-digit year (no leading zeros)
   • /yy (for dual dating) is always 2 digits

   • with an approved qualifier or qualifier pair, from the following list:

   • Abt
   • Aft
   • Bef
   • Bet / and (where both are required)
   • Cal
   • Est
   • From / to (where either can be used alone)

   Examples:
   • Abt 5 Jun 1765
   • Bet 22 Jan 1723/24 and 8 Sep 1730
   • From 17 aoû 1823
   • Est 950
2. If the date cannot be interpreted as a standard date with an approved qualifier (e.g., “winter of 1883”, “young”), display it as entered/uploaded.

Additional options

To be incorporated or deferred at the developer's discretion (but only if there is no opposition)

1. If a date cannot be interpreted as a standard date or approved placeholder ("in infancy", "young"), display it in red.

Abbreviations

Months (English, French and Russian) and how to abbreviate them if entered in full:

January Jan

February Feb

March Mar

April Apr

May May

June Jun

July Jul

August Aug

September Sep

October Oct

November Nov

December Dec

janvier jan

février fév

mars mar

avril avr

mai mai

juin jun

juillet jul

août aoû

septembre sep

octobre oct

novembre nov

décembre déc

yanvar’ ian

ianvar’ ian

fevral fev

mart’ mar

aprel’ apr

may mai

iyun’ iun’

iyul’ iul’

avgust avg

sentyabr’ sen

oktyabr’ okt

noyabr’ noi

dekabr’ dek

Approved qualifiers (English) and how to abbreviate them if entered in full:

about Abt

after Aft

before Bef

between / and Bet / and

calculated Cal

estimated Est

From / to From / to

Show all spouses in search results list

Effort: 2 points

Based on suggestion: Show all spouses in Search Results List

When displaying results for a search on a Person, show all spouses.

Research site speed

Effort: 2 points

Based on suggestion: Site speed – request for faster loading

Get some answers on why pages seem to load very slowly and what can be done about it. In particular, answer whether any of the following items contribute significantly to the problem.

1. server age
2. growth in server capacity not keeping up with growth in site usage
3. the ads
4. running old Javascript
5. running "batch" jobs such as GEDCOM uploads
6. the ever growing list of double redirects

NOTE: This is a research task only, not expected to improve site performance on its own. Results will be reviewed to determine what (if any) actions can be taken to improve performance.

Improve edit conflict merge

Effort: 6 points

Based on suggestion: Change handling of edit conflicts

Minimum functionality

1. When a user attempts to save a page edit on a Person or Family page and the system determines that someone else has changed it in the meantime, present the edit conflict the same as a Person or Family merge, with the saved page on the right and the user’s changed version on the left. Allow the user to select which items to keep from each version, just the same as in the merge functionality.
2. As with the merge functionality, protect the saved version if there are sufficient watchers. The user will be able to add facts, sources, notes and narratives, but will have to explicitly update the page afterward to remove information (e.g., a less precise fact date or a low-value source when a higher-value one has been added). This encourages the user to review other changes made to the page while the user was editing it.

Alternative rule

1. Always protect the saved version (regardless of the number of watchers) to encourage the user to review (in the context of the entire page) other changes made to the page while the user was editing it.

Warnings tool

Effort: 6 points

Based on suggestion: Tool for checking consistency of data (warnings)

Minimum functionality

1. A user can select to run the existing GEDCOM warning edits on the scope of their own watch list and receive the results in a manner similar to the way they are provided in a GEDCOM review.
2. Results to include warnings categorized as alerts, warnings and errors.
3. Allow the user to mark a warning as correct so that it no longer appears on the list.
4. Add this feature to the My Relate menu.
5. Dallan will make technical decisions such as:

   • Whether the display format is the same split-screen as in the GEDCOM review or uses only HTML
   • Whether the list runs interactively, is queued or runs periodically for every user and the results are put on a page for each user that the user accesses through a menu item. Preference is the ability to see a list that is no more than a day old without bogging down the system.
   • How to mark a warning as correct (e.g., with a template on the talk page).

Additional options

To be incorporated or deferred at the developer's discretion.

1. The list identifies the user’s tree(s) for each person or family a warning is produced.
2. A user can select to run the edits for a single tree or sort the watch list results by tree.
3. The edits are run periodically (weekly or monthly) across all users and a summary list of user id, number of warnings and date of last user contribution is placed on a page where all users can see it.
4. The edits are run periodically (weekly or monthly) across the entire database and detailed results are placed on a page (or a series of pages, assuming the volume is large) where all users can see them. The results are not organized by user (because the same results would appear on the lists for many users), but are organized by alphabet, birth century or other means.
5. A user can select to run the edits and have the results include all warnings previously marked as correct. This is useful when someone realizes that their research abilities have matured and that they may have naively accepted incorrect information in the past.

Red links tool

Effort: 1 point

Based on suggestion: Tool for checking consistency of data (red links)

Minimum functionality

1. Allow a user to run the “Wanted pages” query for the scope of their own watch list.
2. Add this feature to the My Relate menu.

Additional options

To be incorporated or deferred at the developer's discretion.

1. When the user clicks the link to see the pages that have a particular broken link, the result is limited to pages they are watching. It is assumed that this enhancement would require a different technical solution than is currently used by the “wanted pages” query, which just uses “what links here”.

Switch to HTTPS

Effort: 1 point

This request was made directly to Dallan.

Make WeRelate more secure by using https instead of http, so that people's passwords aren't being transmitted unencrypted between the browser and the server.

Copy source citations

Effort: 2 points

Add the following functionality to allow a user to copy the details of a source citation (source type, title, record name, image reference, notes reference, volume/pages, date, and text) from one page to another:

The "Copy" feature would be provided on all existing source citations - the "Paste" feature would be provided for all new source citations after pressing the "Add Source Citation" link. Once the copied source citation is pasted, then it would change to "copy" only, as the two source citations S6 and S7 in the example below.

Overview

Each request is a single improvement. As is common practice in software development these days, requests present the minimum change required to realize the improvement. In some cases, additional options are described, but do NOT expect these to be included in the initial change.

These requests are based on community suggestions, which have been reworked to ensure that each request is a single clearly-stated minimally-defined improvement. Suggestions were included based on:

• The number of currently active users who appear to be in favor of the suggestion
• The degree of community consensus apparent from the suggestions page
• The ability to clearly state the requirement
• The need for a programming change (as opposed to a change in conventions or templates)

Below is a list of suggestions that did not quite make the cut, for one or more of the above reasons. This is to acknowledge that these suggestions were not overlooked; however, limited capacity meant focusing on the highest-priority and clearest requests. These suggestions may be addressed in the future.

This list of requests is NOT open to edit by the community, because of the developer's need for a clearly-stated requirement.

Suggestions still outstanding

The following suggestions did not quite make the cut to be presented as requests. See the suggestions page for additional suggestions that generated even less community interest.

• Assertions - does not require a programming change
• Tool for checking consistency of data - duplicate persons - needs rules
• Tool for checking consistency of data - additional consistency checks - needs clear list of rules
• Variant names - less interest from active users
• Exclude unused MySources in Gedcom upload - less interest from active users
• Match MySources in gedcom upload - less interest from active users
• Disallow the deletion of spousal pages if the family page is watched - less interest from active users and needs clarification of exact/complete rules
• Ref Tag improvement - less interest from active users and needs clarification of expectations