feature request - group history section

[Teffania]

low priority

Teffania:
"I've been thinking of both problems with canonlore and possibilities
for added information.

I've particularly been thinking of this screen: (Krae Glas used as the
example, because it is pertinent and geographically close to my heart)
http://www.sca.org.au/canon/branch.php?id=23

The minor problems:
*Gratian doesn't seem to handle groups having different statuses well
without dates for those statuses being listed. (eg Krae Glas was a
canton then became a shire) - there seems to be a bug and possibly
design issues there.
*Even if it's working perfectly and all dates are entered, silly users
can easily misread things. "oh it's a canton" - no it says it was a
canton UNTIL 2004, etc
*my new policy for when groups get entered into canonlore involves
official group status. Which means the formative years of a group may
be missed (but also I don't have to record every abortive attempt to
form a group).

The opportunity for expansion:
*each group has a history, which we are going to ask about to find out
official dates, why not allow them to put this into canonlore?

My proposal:
Just as there are currently tabs for residents, and events, etc under
each group currently, add a tab labelled history. At the top of the
new tab display the full list of dates when the group was various
statuses that is currently on the main tab.
eg
"canton of stormhold until 4/1/2004.
Shire of Lochac from 4/1/2004"

(And just display the current branch status, if gratian can figure it
out, on the main overall tab.)
Below this info would be a large space where groups could submit a
text based history of their group. This could include information
like "the group first started as a proposed group under the
sponsorship of Rowany in June 2000, when John, already an expereinced
SCA'er moved to the area and placed an advert in the local newspaper.
After a sucessful first feast, the group grew in size until 2006 when
they had enough numbers and a registered device and applied to become
an official group." etc

Such a free text field would require little effort from furture canon
heralds to maintain, and responsibility for creating hte text could be
delegated to groups.

I'm not sure if this would be difficult to program - I think the only
tricky bit would be the strange behaviuor of the gratian in working
out group status - which it is already sometime screwing up anyway."

[Paul Harrison (paul-francis-harrison)]

I will remove the "from unkown" and "to unknown". Does "to unknown" always mean "currently"? Extra emphasis could be given to such a status on the web page.

Free text field sounds good.

[Teffania (teffania)]

On 28 June 2010 10:30, Paul Harrison <email address hidden> wrote:
> I will remove the "from unkown" and "to unknown". Does "to unknown"
> always mean "currently"? Extra emphasis could be given to such a status
> on the web page.

Nah, in the groups section, "to unknown" sometimes means to current
and sometimes just means an unrecorded date.

Since I'm informed that gratian can't cope with fuzzy dates in this
field, there will be a lot of unknowns as this detail is difficult to
obtain. Having the words unknown on the page isn't so much of a
problem, except where it means current, as it often solicit's info
from people who know.

I suspect this might be a case where Gratian's cleverness has served
less well than plain text would because it underestimated the
bodgyness of the data, and stupidity of humans.

The way I see it there are a few problems tied up in this:
1) Humans get easily confused when there are mulitple branch types on
the main branch page, even when they are provided with dates. I think
there really needs to be a way of making the current group status much
more promient than former group statuses. This could be hiding the
former group statuses on annother page as I suggested, or it could be
making the current group status in a bigger typeface or similar.
2) I'm not sure that Gratian can always reliably work out which IS the
current group status. I'd need to know a bit more about how it works
that out. I think a lot of the records display correctly because I
leave out the former group statuses until I know everything about
them. Tied in with this is that gratian kinda knows when a group is
closed (the became field), but this isn't tranparent in a user
friendly (to a casual user) way either.
3) It's really difficult to determine the exact date when a group
officially changed status. There are very few records kept of group
status (I'm having trouble even now determining which groups are
incipient), those that are are unreliable, and most of the records
aren't based on abosolute dates, which makes it a real pain to try and
track a chronology.

I think I'm afraid this might actually be a whole redesign project in
itself, hence the tag wishlist, rather than any other tag. I find the
more I try to pin this down, the more the gratian side of it eludes
firm description in nice programmable terms, which worries me. But
there probably is still something that can be done on the canonlore
side to make things a bit better. Normally I'd say just do what seems
sensible, but I think in this case, I don't understand enough about
what you'd do, and think i's a minefield, so if you could manage some
kind of quick visualisation, that might help. Cos I'm much more
confused the more I learn about this bit of the interface.

Teffania

On 28 June 2010 10:30, Paul Harrison <email address hidden> wrote:
> I will remove the "from unkown" and "to unknown". Does "to unknown"
> always mean "currently"? Extra emphasis could be given to such a status
> on the web page.
>
> Free text field sounds good.
>
> --
> feature request - group history section
> https://bugs.launchpad.net/bugs/501228
> You received this bug notification ...

[Paul Harrison (paul-francis-harrison)]

Just looking at the code in canonlore, branch.php, line 86-92: It looks like there is a test for whether or not there are from and to dates. Some branches display as you would expect, eg: http://www.sca.org.au/canon/branch.php?id=28 has no "to unknown". Others do not, eg: Krae Glas http://www.sca.org.au/canon/branch.php?id=28 which has a "to unknown".

I note in the Krae Glas page that the link for "from unkown" is 1900-01-01, the link for "to unknown" is 3001-01-01.

The php documentation for "date" says: "The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). However, before PHP 5.1.0 this range was limited from 01-01-1970 to 19-01-2038 on some systems (e.g. Windows)."

I think therefore that the "unkown" dates are perfectly valid dates that php is silently failing to cope with.

Gaaaaaaaaaah!

One thing I can fix: currently no dates will be shown by canonlore if there is a "to" date but no "from" date.

[Teffania (teffania)]

On 28 June 2010 12:09, Paul Harrison <email address hidden> wrote:
> Just looking at the code in canonlore, branch.php, line 86-92: It looks
> like there is a test for whether or not there are from and to dates.
> Some branches display as you would expect, eg:
> http://www.sca.org.au/canon/branch.php?id=28 has no "to unknown". Others
> do not, eg: Krae Glas http://www.sca.org.au/canon/branch.php?id=28 which
> has a "to unknown".
>
> I note in the Krae Glas page that the link for "from unkown" is
> 1900-01-01, the link for "to unknown" is 3001-01-01.

This was my bodgy attempt to see if it would fix the incorrect
display. (so noted in notes in gratian) I definately only did this to
Krae Glas (cos I'd look at it often enough to notice I'd done that) to
see if it would fix things. Please feel free to change these back to
unknown.

> I think therefore that the "unkown" dates are perfectly valid dates that
> php is silently failing to cope with.

So gratian probably needs to refuse them? I need to check a doccument,
but I think there isn't a problem with lochac branches starting from
1970. (as in I think all are 1980's forward).

> One thing I can fix: currently no dates will be shown by canonlore if
> there is a "to" date but no "from" date.

So Darton (which hasn't been bodged by me) currently shows:

"shire in Caid
shire in Lochac since 10 May 2003"

which is confusing plenty of people, Do I understand, you'd fix this
so it would say:

"shire in Caid until 10 May 2003
shire in Lochac since 10 May 2003"

see also bachuss wood:
http://www.sca.org.au/canon/branch.php?id=14
Where I have fix me messages from people saying - "but we are a shire,
not a canton!"

This would definately be nicer. Please do this if it is easy.

Not the whole solution, but a useful step in the right direction.

[Paul Harrison (paul-francis-harrison)]

The problem with dates like 1900-01-01 and 3001-01-01 is just with php, not with mysql or gratian. If it needs fixing, the fix will be to canonlore's php code. Just, we shouldn't rely on this behavior from php.

I will fix canonlore so Darton and Bachuss Wood display correctly. These are useful examples :-)

[Paul Harrison (paul-francis-harrison)]

Darton now displays correctly. Bachuss Wood does not have an end date for its time as a canton.

[Teffania (teffania)]

On 28 June 2010 17:54, Paul Harrison <email address hidden> wrote:
> Darton now displays correctly. Bachuss Wood does not have an end date
> for its time as a canton.

Yes, I think this is a major design problem - that the interface
assumes absolute dates can be researched, and really I'm not convinced
they are. In most cases it's a case of the data has been lost due to
lack of recordeing, but in some cases, I think it the ceremonial
process may have been insufficiently formal that no clear date can be
determined.

I suspect the group history dates bit needs complete rethinking. This
sounds like a big job to me, and I suspect one no-one is willing to do
right now. (and I'd prefer the gratian awards dialog redesign was
implemented earlier anyway)

Is there an easy way to make Bacchus Wood (or any other entry with a
former status with no details, or only fuzzy date details) display
only it's shire status for now as a temporary fix?

This page:
http://www.sca.org.au/canon/branch.php?show=subs&id=3
does something funky to determine the current status of groups, and as
far as I can tell, gets them all correct except perhaps Krae Glas (not
on the list - wonder if any other shires are missing too?)

If it's not quick then, I'll just have to not enter branch statuses
with fuzzy dates until I know firm dates. (which is how the majority
of the database is).

Teffania
p.s. My non-programmer brain says the solution to this is to have a
current group status tickbox/tag in gratian and let the smart human
decide which is hte current status, rather than the very linear
computer. but I think I might be thinking to literally.

[Paul Harrison (paul-francis-harrison)]

The subbranch display is based on history records with a null "to" date (canon-branch.php / GetSubbranches).

To fix Bacchus Wood you could delete the canton history record, or give it a to date (20 April 2003?). To fix Krae Glas, you should delete the "to" date from its shire history record.

Is the history used in any computations or searches, or would just the current branch type and current branch parent be enough for everything? If the latter, I would advocate adding the current branch type and current parent branch to the branch table, and storing the branch history as a free-form text field, again in the branch table.

[Teffania (teffania)]

On 29 June 2010 13:17, Paul Harrison <email address hidden> wrote:
> To fix Bacchus Wood you could delete the canton history record, or give
> it a to date (20 April 2003?). To fix Krae Glas, you should delete the
> "to" date from its shire history record.

Will try to remember to do this on the weekend. Was suffering under
shaped internet at home the last few days. Or feel free to do this
yourself.

> Is the history used in any computations or searches, or would just the
> current branch type and current branch parent be enough for everything?
> If the latter, I would advocate adding the current branch type and
> current parent branch to the branch table, and storing the branch
> history as a free-form text field, again in the branch table.

I can't think of anything that looks like it might, I suspect it was
instead a opportunity for expansion and also it's easy to just add a
new entry when a status changes, rather than transfer text between
types. But we really need Bat to answer that question authoratively.

Please note: my original proposal mentions of a free text field was a
whole page for people to write about their branch history, rather than
just a few dates. (possibly done via html rather than the tables?) But
that was a very wishlist part of the proposal. The fixing of the
people + multiple visible branch dates=confusion was the core bit.

[Teffania (teffania)]

Deleted fake from date from Krae Glas. Unable to reach to date due to vista formatting issues.
(https://bugs.launchpad.net/gratian/+bug/592149)

Accidentally compounded Bacchus wood values due to vista formatting issues.
(https://bugs.launchpad.net/gratian/+bug/592149) and undo not working bug (https://bugs.launchpad.net/gratian/+bug/578812) interacting.

Can someone else please edit these as Paul described:

Krae Glas
canton from NULL to 4 Jan 2004
shire from 4 Jan 2004 to NULL

Bachus wood
canton from NULL to 21 Apr 2003
shire from 21 Apr 2003 to NULL

remove notes relating to this from record too.

[Domhnall (actreal)]

Attempted to edit dates as requested by Teffania.

Unable to reach to date due to Windows (not just XP) formatting issues.
(https://bugs.launchpad.net/gratian/+bug/592149)

[Teffania (teffania)]

bug now fixed, krae glas dates fixed. To do Bachuss woods.