This is the place to leave comments about the ToDo list, to request new things be added to the ToDo list or request that something on the ToDo list be done as soon as possible for example.
Family Tree Explorer [25 October 2008]
Creating source pages and addition to Trees [26 October 2008]
When I create a Source page (or Repository, I think, as well), I need to un-check the 'add to tree' selection at the foot of the editing page in order to not have the new page added to a particular tree by default. Are there preference controls available to modify this behavior? To block the auto-check function? To change the default tree to add a new Source to? This is important for those people who are engaged in Source Review activities in particular. --ceyockey 10:44, 25 October 2008 (EDT)
If I could jump in for a sec. I have (had) the same problem Ceyockey and requested the same feature some time ago, i.e., there be some kind of setting in our preferences to determine which tree is the default or decide what type of page gets added to a tree. As a work around, I have a created a "dummy" tree that alphabetically (since pages by default get loaded into the first tree in the list) comes at the beginning of my list of trees. I can never remember to uncheck the page from being added to a tree, so at the very least, this dummy tree catches all those pages that I don't want added to my Family Trees. I believe Dallan is thinking about doing away with the "Tree" concept (which warrants further discussion) so this problem may only be temporary. BTW, the name of the first tree in my list is AAA, which right now is holding all kinds of pages that I want to review, source or ditch, not just those pages that I added accidentally. Pages can also be in more than one tree, so having specific trees for specific tasks (questionable relationship, research further, contact author, junk, etc) is really handy for "tagging" pages. --Ronni 13:53, 26 October 2008 (EDT)
This question is an example of why I'd like to replace trees with something else. In a sense we're using trees similarly to categories, so one possibility is to suggest that people use categories for those cases when they want to tag pages. Adding a page to a category requires editing the page, so it seems kind of "heavy". On the other hand, categories are searchable (just enter Category:title in the keywords box), and it would be fairly straightforward to extend watching a category to being notified whenever any page in that category is changed.
Another possibility is to come up with our own tagging capability, like http://del.icio.us, but this represents some work, so why not suggest that people use delicious or one of the existing taggers? If we implemented our own tagging mechanism, we could add the ability to use tag names in searches; would this be that useful, or would just listing your tagged pages (which you could get by tagging them with delicious) be sufficient? I just added a topic to the WeRelate talk:Watercooler on this. I'm hoping to get a discussion going.--Dallan 23:53, 28 October 2008 (EDT)
add pages for person/family "red links"? [27 October 2008]
Is it your intention that WeRelate would automatically add person/family pages that would ordinarily be "red linked"? They could be red-linked because of a simple data-entry oversight. I responded to a question from a user last week where they inadvertently put the character & between two names in a title, instead of the word and. How about a report of red-links (and the page it appears on) per user instead?--JBS66 10:49, 27 October 2008 (EDT)
Until a few months ago, when you added a husband, wife, or child to a family page, the system would reserve an index number for that individual but would not create the person page. So it would create a "red link" to a non-existent person page. The thinking at that time was that when you were ready, you would click on the red link to create the page. Red links were similarly-created when you added parents or a spouse-family to a person page. A few months ago I changed "Find/Add" to always create the page. Now the only time red links are created is when you enter a title that includes an index number for a page that does not exist. (After seeing the problem you responded to, I decided that in the future I want to block people from doing this.) So even though there are some exceptions, I believe the majority of red links were created several months ago when people reserved the index number but did not create the page.
Two issues with red links: A lot of people want to re-use index numbers when pages get deleted. So if "Person:John Smith (1)" is deleted, the next time someone tries to create a page for John Smith they get a page titled "Person:John Smith (1)". The red links complicate re-using index numbers. Also, red links don't show up in search results, so if I do a search for John Rarename married to Mary Oddname, I don't get a result even if "John Rarename and Mary Oddname (1)" is listed as a red parent link on a person page.
The report is a good idea. I could come up with something like that.--Dallan 23:53, 28 October 2008 (EDT)
New item? Failure to jump to sections when clicking on section links in Histories [27 October 2008]
One feature of the MediaWiki software is that a link like User:Dallan/WeRelate_ToDo_List will jump to the top of the designated page while User:Dallan/WeRelate_ToDo_List#Low will jump to the section named "Low". This does work for an in-line link like that in the last sentence. However, it is not working for the "→" links in the page History. I'm wondering if this is a MediaWiki software bug or a problem in the WeRelate configuration? Personally, I find the → links to be very useful. --ceyockey 22:24, 27 October 2008 (EDT)
The problem is the automatically-added dates in the section headings. I find the dates useful to see as part of the table of contents, especially for the watercooler, but they do wreak havoc with section links. I'd like to replace the current watercooler with something that looks like what they have at wikia. If I did that, then I think I could get rid of the dates on the section headings, which would make the links work again.--Dallan 23:53, 28 October 2008 (EDT)
If I were to try to flesh out some of the listed requirements/bugfixes ... [1 November 2008]
...where would you want the expanded content to be put? For instance, the first High item "wider More menu; orange triangle?" is quite understandable without being illustrated, but it could be described in more detail along with a "new version" picture. That is one that might not be worth the effort, but the next one on the list "Browse bugs: articles, /'s in titles not decoded correctly" is one that would benefit from example and description so that the general contributor "public" might be able to comment on it. I am not asking for you to do this; rather, I'm asking if I were to try and illustrate / expand some of these, where would you want these expansions put? --ceyockey 22:28, 27 October 2008 (EDT)
How about under WeRelate:Todo list? If you're interested in doing this, I'm open to having the Todo list moved to the WeRelate namespace so that you and others could edit it directly. I don't want others to add items directly to the todo list, but I think that could be managed. Just copy-and-paste it over if you like and I'll redirect this page to that page.--Dallan 23:53, 28 October 2008 (EDT)
New page and structure creation [5 November 2008]
Add an image page [28 October 2008]
When I add an image and need to enter text into the "text box" at the bottom, the format buttons are not there to help with the "bold" and insert signature, etc... Can those be added to the initial format page? Otherwise I have to go ahead and save the image page, then go back into it to edit the text box, which seems like a silly extra needed step. --Kristy 13:36, 28 October 2008 (EDT)
I'll add this. It will start off as a low-priority item; if more people say this is important, I'll move it up.--Dallan 23:53, 28 October 2008 (EDT)