branch closed text/layout confusing

Bug #600890 reported by Teffania
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canon Lore
Triaged
Medium
Unassigned

Bug Description

from a january 2008 wishlist of teffania the brand new canon herald:
*Something that makes it clearer that a branch is closed or in permanent abeyance (colleges). The “became” is not very clear. Perhaps a field for branch closed, which shows up on the website as something like “branch closed May 2006, became part of Stormhold”. The date field could not be a simple date field of dd/mm/yyyy, but would have to have some flexibility for answers such as “before 2004″, “may 2006″, etc.

Eftb's response in Jan 2008:
* Branch status improvements: will require a little fiddling, and may not be as flexible as that, but I can improve on the status quo. Priority 2/5 Difficulty 3/5.

Current status:
*YES, I'd still like this. I still get confused people ocasionally.
It would also be cool if this screen could tag groups on this list:
http://www.sca.org.au/canon/branch.php?show=subs&id=3
as "the former ..." as appropriate eg "the former shire of Llyn Arian"

Teffania (teffania)
Changed in canonlore:
importance: Undecided → Medium
Revision history for this message
Eric TF Bat (bat-flurf) wrote :

We probably need to bite the bullet and add a field to the canon_branch table, like "branch_status enum ('incipient', 'active', 'closed') NULL", and then make suitable adjustments to Gratian and CL to use it. I didn't do that because I thought it would be OK provided we had proper dates, but that's harder than I thought.

Revision history for this message
Paul Harrison (paul-francis-harrison) wrote :

I've made some changes that will hopefully reduce confusion.

Anything that "became" anything else is now listed as "former" in the branch listing.

Any history item with a "to" date is listed as "was a ", eg "was a canton in Stormhold from ... to ...". If a history item doesn't have a "to" date but the branch became something else, the history item is listed as "formerly a ", eg "formerly a canton in Stormhold from ...".

Are there any examples of branches that simply ceased to be?

Changed in canonlore:
status: New → Triaged
Revision history for this message
Paul Harrison (paul-francis-harrison) wrote :

by the way, um,

Vallum Vespertinum
    * formerly a canton in Stormhold
    * became Stormhold

A literal reading of this would be that Vallum Vespertum travelled back in time so that it could be its own parent branch. Surely it was formerly a canton of Lochac? It would also be nice to have an end date for its history as a canton, so it isn't listed as a sub-branch of anything.

There are several branches like this.

Revision history for this message
Canon Herald (canon-lochac) wrote : Re: [Bug 600890] Re: branch closed text/layout confusing
Download full text (3.6 KiB)

> Vallum Vespertinum
>    * formerly a canton in Stormhold
>    * became Stormhold
>
> A literal reading of this would be that Vallum Vespertum travelled back
> in time so that it could be its own parent branch. Surely it was
> formerly a canton of Lochac? It would also be nice to have an end date
> for its history as a canton, so it isn't listed as a sub-branch of
> anything.

I never checked out the doccumentation of this feature properly before
so I had been entering data incorrectly.
http://lochac.sca.org/herald/table_branch
Technically when a branch closes, the people therein get transferred
to the new owner of the land (for a canton the barony, for a shire the
crown or sometimes a nearby barony).

We might never have dates of when some of these cantons closed.
Especially not precise ones. (Can this manage fuzzy dates? I can't
tell from the docco). So how do we denote closed branches with closure
date unknown?

So, from this confusion and the other bits you've mentioned, I guess
we need to properly think through al the options of what a branch can
be and do with a view to seeing what can be redesigned and what can be
fudged. I will attempt that here:

1) A group starts and changes name sometime. Including cases where a
group closes down for technical reasons and a suspiciously similar
group starts with almost identical territory a few months later.
We might not know the dates, but we will likely be able to fill the
field became.

2) A canton or college starts and then folds. The members and
territory become part of the parent group. While a date to will exist
for the current status (college and cantons are unlikely to have other
statuses although shire>canton is possible) it is unlikely to be
actually known. Technically this doesn't become anything else - only
it's members and territory do, so "became" perhaps should be Null.

3) A shire folds. Territory is likely to become part of the kingdom,
although in several cases founding baronies in each state get fairly
automatic claim to all unclaimed territories in the state, so the
territory may revert to the founding barony until a new shire starts
in the area, or the land may remain crown land. While a date to will
exist for the current status it is unlikely to be actually known.
Technically this doesn't become anything else - only it's members do,
so "became" perhaps should be Null. A shire may well have formerly
been a canton. While the relative order of these two statuses may be
known, without dates, this may not be entered into gratian.

4) A current group - the became field must be null, the "to" field of
the current group type (eg barony) must be null. The from date of the
curent type and to date and from date of former statuses may be
unknown.

I'm inclined to think that either I need to be able to put in a
"unknown" value in the to and from dates (ie the branch closed on date
"unknown" but is definately closed, a different option from the field
is null) or a seperate branch status field (ie closed, active) is
needed. Are there other neat ways of dealing with this that I haven't
thought of?

Since that's a gratian project, and we are discussing what we can do
in canonlore, I'...

Read more...

Revision history for this message
Canon Herald (canon-lochac) wrote :

did i say lovely work? Tis!

Revision history for this message
Paul Harrison (paul-francis-harrison) wrote :

The current model of branches and history records is growing on me. An elegant way to represent a tree changing structure over time. Possibly the only change that needs to be made is a way to distinguish a history item that ended on an unknown date from a history item that is still current. Fuzzy dates are nice... is it possible to have a completely fuzzy date distinct from null?

People who are residents of branches which are closed (= branch with no current history record, irrespective of whether the branch "became" anything else) is a problem. Is there any system in place to ensure this doesn't happen? Maybe not desirable if someone stopped playing before the branch dissolved. Alternatively we could make sure that every branch has a current history record, and allow a "dissolved" branch type -- this would allow us to specify a parent branch during a period of non-existence, and ensure people in closed branches appear in orders of precedence, member lists, etc.

"became" could also be a type of history record, with the branch that it became as the parent. Possibly this is stretching the concept a little, but it would make the code straightforward. (Having Vallum Vespertinum as a canton in Stormhold has a similar effect... anyone who is listed as a resident of Vallum Vespertinum will show up in the Stormhold order of precedence.)

Revision history for this message
Teffania (teffania) wrote :

On 16 December 2010 17:06, Paul Harrison <email address hidden>wrote:

> Fuzzy dates are nice... is it possible to have a completely
> fuzzy date distinct from null?
>

I think that it might make life a lot easier if we had one - but how much
work to implement it?

> People who are residents of branches which are closed (= branch with no
> current history record, irrespective of whether the branch "became"
> anything else) is a problem. Is there any system in place to ensure this
> doesn't happen?

No systematic way of ensuring this. There are occasional audits done by me
and helpers. With the exception of stegy (which is a special case of
messiness - it's really a became, but policy prevents entry of a new name
until the branch is official), the other closed branches should only have
members who stopped playing while that branch was still alive, and have not
played since. One trouble is there is seldom a proper official announcement
that branch is closed.

I've been considereing if it might be nice if there were some sql reports
canon could regularly run to check on the database data. eg people with no
listed group.
I think people who belong to closed groups, especiially ones who have
recieved their last award after the group closed would be a useful one.
then again I don't know group closure dates, so maybe just people in closed
groups, with the date of thir last award (or registration once we have a
place for that)

> Maybe not desirable if someone stopped playing before
> the branch dissolved. Alternatively we could make sure that every branch
> has a current history record, and allow a "dissolved" branch type --
> this would allow us to specify a parent branch during a period of non-
> existence, and ensure people in closed branches appear in orders of
> precedence, member lists, etc.
>

oooh, I like that idea. Dissolved branches. nice lateral thinking.
 so colleges could me marked witha status of abayance, other groups as
closed, and there would even be future provision for me to enter proposed
groups (not allowed by policy currently, but maybe we could work out
something silent)
became could be reserved for group name changes, and parent group of
dissolved could be for where members get automatically transferred to by
registry.

please develop this idea further, tell me a bit more about consequences and
effort required....

people in closed branches I thought would appear in the parent's group OP?
hmm, I was still requesting that change wasn't I?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.