Ticket Review 16 March 2007

Date: 2007-03-23 11:01:19

Agenda: http://icon.stoa.org/trac/pleiades/wiki/TicketReviewAgenda2007-03-23

Chairs

  • Tom Elliott (paregorios)
  • Sean Gillies (sgillies)

Participants

  • Gabriel Bodard (gbodard)
  • Hugh Cayless (hcayless)
  • Tom Elliott (paregorios)
  • Sean Gillies (sgillies)
  • Chris Lilley (nantonos, chrislilley)
  • Brian Turner (bdturner)

Topics

Issues

Action Items

  • sgillies to write a GenericSetup story in the wiki [continuing]
  • paregorios to consult community about place types [continuing]
  • paregorios to open ticket for an alternative name id and duplicate handling solution [new]
    • update 23 March: done; see new bug #294
  • paregorios to write CommunityAndCanonicalHelpStory? and req comments via community list [new]
  • paregorios to discuss bug #239 with community [new]
    • update 23 March: in progress; email sent
  • paregorios to engage community in describing (and translating) vocabulary terms [new]
    • update 26 March: sent note to pleiades-community list about name-type vocab

Transcript

Please note: this transcript has been edited for clarity.

Introduction

  • paregorios: welcome to ticket review!
  • paregorios: my fiendish plan is to follow the agenda
  • paregorios: so first review of action items from last review, then sgillies will lead us on a spring romp through the tickets for milestone:"Sensible Help"
  • paregorios: any objections?

Open Action Items

  • sgillies: i'm still wrestling with it. it's a long one and i need to email the plone product developers list with some questions first
  • paregorios: ok
  • paregorios: ACTION: sgillies to write a GenericSetup story in the wiki [continuing]
  • sgillies: Jon Stahl has written a product developers doc, and i would like to see about adding some generic setup guidance to it
  • paregorios: I think that's a really good idea
  • paregorios: the Plone community is trying to improve it's plugin/3rd-party development story
  • paregorios: trying to lay in better support, models, etc.
  • paregorios: if we can contribute to that effort, I think it would be good
  • sgillies: on to tickets?
  • paregorios: just a sec
  • paregorios: ACTION: paregorios to consult community about place types [continuing]
  • paregorios: I want to wait to do this until we've got a bit further on user stories
  • paregorios: so leaving it open
  • paregorios: ok, now on to tickets

Ticket Review For milestone:"Sensible Help"

Issue bug #93

  • paregorios: ISSUE: bug #93
  • paregorios: I guess bug #93 is mine
  • paregorios: at the core of my work for the coming week
  • paregorios: I want to refactor so we aren't using urls and locations to effect the linkage between the context and the help
  • paregorios: I plan to use the plone keywords mechanism instead
  • paregorios: questions or concerns?
  • sgillies: i'm going to presume that everyone is stepped through tickets with us using the "Next Ticket ->" link at the upper right of any ticket page
  • sgillies: none

Issue bug #199

  • paregorios: ISSUE: bug #199
  • paregorios: bug #199 is a specific help document
  • paregorios: and is really subordinate to bug #217 (which is next)

Issue bug #217

  • paregorios: ISSUE: bug #217
  • paregorios: any comments on those?
  • sgillies: let's add the dependency
  • paregorios: what's our syntax again?
  • sgillies: depends on: #n
  • paregorios: the dependency for bug #199 is really on bug #93
  • paregorios: can't do 199 without 93 being in place
  • paregorios: bug #217 is dependent on bug #93 simply because of a part-of relationship
  • paregorios: I'm putting them in
  • sgillies: lat, lon is specified by EPSG
  • paregorios: can you add that comment?
  • sgillies: for EPSG:4326
  • sgillies: it's frustrating, but there it is
  • paregorios: dependencies are in

Issue bug #218

  • paregorios: ISSUE: bug #218
  • paregorios: as I understand it, we still need landing (index) pages for both "locations" and "names"
  • paregorios: sgillies: what was the "issue" with locations?
  • sgillies: hang on, we had a collision, and the web ate my comment
  • paregorios: greedy beast, that web
  • paregorios: sorry
  • paregorios thought he was clear
  • sgillies: ok, bug #218
  • paregorios: the blocker to adding a landing page to locations was the local content model, yes?
  • sgillies: let me take this one from you since i'm working very close to it
  • sgillies: yes, that, and also because i don't want to lead users into the location container
  • paregorios: agreed
  • paregorios: I was going to ask
  • paregorios: what constitutes good landing pages for locations and names
  • sgillies: there's little sense to be made of them in any non-spatial context
  • paregorios wants to hide the "duplicate names" solution from users
  • paregorios: b/c it will have to change
  • paregorios: and anyway, they don't care
  • nantonos: why will it change?
  • nantonos: isn't there a need for multiple alternate names
  • paregorios: right now, names are id'd by the ascii transliteration of the name string
  • paregorios: these ids must be unique in the container
  • sgillies: primary keys
  • nantonos: ah, ok
  • paregorios: the solution that worked for this dataset was to dump dupes in the duplicate names subfolder
  • paregorios: but as we add more data we will get trips, quads, and more
  • paregorios: so the current mechanism will fail
  • paregorios: the associations with place and location are handled by references
  • paregorios: this is just about buckets for storing the stuff
  • paregorios: sgillies: are you therefore taking the landing issue for both names and locations?
  • sgillies: paregorios: users will eventually resolve all the duplicate names, right?
  • sgillies: ideally
  • sgillies: resolve the duplication issue by renaming or deleting them
  • paregorios: no
  • paregorios: it's simple human practice to use the same sequence of characters for more than one place
  • paregorios: I call where I live Huntsville
  • paregorios: so do some folks in Texas call theirs
  • paregorios: two distinct places
  • paregorios: two distinct (but identically spelled) names
  • paregorios: nothing to be "resolved"
  • sgillies: now i'm with you
  • paregorios: we must either adopt something other than name.title for our ids
  • paregorios: or come up with a different bucketizing mechanism
  • sgillies: the former
  • paregorios: +1
  • paregorios: whatever we do potentially has an impact on simple and sane urls
  • sgillies: we've fallen off of bug #218
  • nantonos: I briefly wondered about the wikipedia solution of short page names and disambiguation pages
  • nantonos: but perhaps not
  • sgillies: second thought, you keep bug #218 and learn about generic setup through it
  • paregorios: sgillies: that's fine by me
  • paregorios: but I don't think we're off topic for that bug
  • paregorios: we may need *another* bug #for a dupes solution though
  • sgillies: definitely
  • paregorios: ACTION: paregorios to open ticket for an alternative name id and duplicate handling solution
  • sgillies: off the top of my head: we keep the existing names, and re-implement plone's id handler to suggest alternatives in the case of already existing ids
  • paregorios: nantonos: I think there's probably an issue for users there ... they will eventually want help disambiguating duplicates in, e.g., search results
  • paregorios: sgillies: that was what I was thinking
  • sgillies: ... that would lead to "xanthos", "xanthos-foo", etc
  • nantonos: seems like you can either make all names long, or you can pick a most important name and make the others long, or you can use one level of redirection as needed
  • paregorios: picking "most important" would be very difficult
  • sgillies: community norms would give us sensible ids
  • nantonos: agreed
  • sgillies: should give us :)
  • paregorios: sgillies: elaborate?
  • sgillies: we don't want people entering "xanthos-misc" for the id of the second Xanthos, but it would be dumb to code something that can be managed by community norms
  • paregorios: how do we determine community norms for the legacy batlas data
  • paregorios: which we are loading piecemeal into pleiades in arbitrary order
  • paregorios: but for which we would like to provide persistent urls as soon as practical (as we've already done at the place level)
  • sgillies: i suspect that there will be sensible identifiers in the xml which we can use to disambiguate
  • paregorios is not sure having users enter ids for names is something they will want to do
  • sgillies: let's table this and get back to it after the tickets
  • paregorios: right - we have an action item for it
  • bdturner: I have some thoughts for later
  • paregorios: bdturner: cool

Issue bug #220

  • paregorios: ISSUE: bug #220
  • paregorios: this is actually at the top of the dependency tree we trundled into with bug #93
  • nantonos: Why is "change the linking mechanism from url fragments to keywords or relations" better?
  • paregorios: the way I'm doing it now the url fragments (unique ids in containers) in the path have to match at a certain point
  • paregorios: with
  • paregorios: class and attribute names in the content object models
  • paregorios: ugly and cumbersome
  • paregorios: and a single help topic can't then be reused in multiple contexts
  • nantonos: okay
  • paregorios: I've added a dependency relationship with bug #93
  • sgillies: cool
  • paregorios: anything else on this bug?
  • sgillies: would be nice if it aligned with our new vocab views
  • paregorios: can you add a comment to that effect on bug #220?
  • paregorios: for helpish content that maps well onto a list of terms, I think that's a good idea (i.e., reference-style help)
  • paregorios: for concepts and tasks, we'll need something else
  • sgillies: agreed
  • paregorios: ready to proceed to next bug?

Issue bug #229

  • sgillies: ISSUE: bug #229
  • paregorios: sgillies: I think I asked you before, but don't remember the answer
  • paregorios: what's needed here?
  • sgillies: a generic setup config file
  • sgillies: ask me when you get to this one
  • paregorios: ok
  • paregorios: that's mine
  • sgillies: trivial, but will need testing

Issue bug #232

  • paregorios: ISSUE: bug #232
  • paregorios: what do people think of this idea?
  • sgillies: +1
  • nantonos: would it imply a need for help aggregation?
  • sgillies: the best could be distilled into "official" portal help
  • bdturner: does this mean I'll have a list of personal helpfiles I used often?
  • paregorios: it would mean that you'd have a collection of helpfiles that you authored
  • bdturner: oh!
  • paregorios: they could either be drafts ... in which case they'd stay your personal stuff
  • paregorios: or they'd get workflowed to published status (by someone with appropriate role permissions), and then they'd be global
  • bdturner: useful...but I am concerned about "clutter"
  • paregorios: they'd need to be marshalled into some kind of central view
  • paregorios: there are two models with plone, aren't there
  • bdturner: clutter = to many files and folders and buttons etc
  • bdturner: OT I like it
  • paregorios: bdturner: I think we'd try to have a pretty clean view of a list of documents, with some kind of sensible top-level organization
  • paregorios: but we'd also put fairly discrete links, or a single portlet with links in it, on other pages ... providing access to only those help docs (wherever they are) that are relevant to the user's current work context
  • bdturner: implied... I just wanted to make the point... especially for people (like me) not familiar with plone... to many options can be skeery
  • paregorios: yes, I know the front page is still an issue there too (I think we have a ticket for that)
  • bdturner: probably off topic now
  • bdturner: re: front page - yes
  • bdturner: definitely off topic now
  • paregorios thinks the default plone layout and portlets collection is mostly about showing off what plone can do
  • bdturner: makes sense
  • chrislilley recovers from blue screen :(
  • sgillies: yeah, we'll do away with some of the clutter soon
  • paregorios: chrislilley: where did you check out
  • sgillies: bdturner: i think the calendar is not very useful
  • chrislilley: I was only gone for a couple of minutes
  • paregorios: you were right about needing help aggregation, which I think we can pretty easily do on the basis of plone keywords
  • chrislilley: yes
  • paregorios: using Plone "smart folders" and workflow states
  • bdturner: calendar... but I'm mostly concerned with the redundant buttons and multiple folders which I think can be collapsed into one or two at most....again probably tangential
  • chrislilley: if multiple people create help then a help query has multiple sources to draw on
  • paregorios: the navigation portlet is problematic
  • chrislilley: thus, how is it aggregated
  • chrislilley: or, you can say there is system help and user help
  • chrislilley: just two sources
  • paregorios: chrislilley: you mean the collisions problem again?
  • bdturner: re: multiple help files... redundancy? will show two ways to do the same thing?
  • chrislilley: and i don't benefit from your help until it gets promoted to system
  • bdturner: sorry... redundancy
  • chrislilley: yes
  • bdturner: re: two ways of completing same task... useful... confusing to new users???
  • paregorios: one model for solving this is to have "canonical" help and "community-generated" help
  • chrislilley: in other words do people only see their own local help, so it's like a prototyping service, or do we see everyones?
  • bdturner likes idea but is playing devil's advocate
  • bdturner: ditto Chris' comment
  • paregorios: we *could* (depending on cycles) treat as follows
  • paregorios: help gets surfaced in one of two ways
  • paregorios: field-level reference help (that is marked as "published" and "canonical") gets links generated to it next to widgets in appropriate views
  • paregorios: higher-level, but context-relevant help of any type shows up in a portlet
  • paregorios: such help if marked as "canonical" would be at top in portlet
  • paregorios: then under a subheading, you'd get anything that was at the community level
  • paregorios: part of the process of moving something from community to canonical would be disambiguation, consolidation and relocation to a central place
  • paregorios: therefore a function of the managing editors, development team and others press-ganged into helping
  • chrislilley: that sounds like a workable plan
  • bdturner: agreed
  • paregorios: how about I write this up as a story in the wiki and hurl it at the community list for reaction?
  • bdturner: +1
  • sgillies: sounds good. shall we go on to bug #238?
  • paregorios: it won't slow work on the other help-related tix as alot of this is business rules and query criteria
  • paregorios: ACTION: paregorios to write CommunityAndCanonicalHelpStory? and req comments via community list

Issue bug #238

  • paregorios: ISSUE: bug #238
  • paregorios: I don't think this is hard, once I figure out how to force execution of a field validator
  • bdturner: re: 238 ... same code as when I try to save something and use a "." in the file name??
  • bdturner: computer says NO
  • paregorios: there are plone hooks for this, I just haven't done it before
  • paregorios: bdturner: same general idea
  • sgillies: yep
  • sgillies: we could even spell it out as a regex
  • paregorios: +1
  • sgillies: for those that like regex :)
  • paregorios: it's what I'll use in the code
  • sgillies: i assume digital humanists are familiar with regular expressions
  • paregorios: it's pretty easy, it has to be [a-zA-Z]+
  • paregorios: if they're not, they need to become so
  • chrislilley: um, hang on there
  • paregorios: sorry, no that's for nameTransliterated
  • chrislilley: all names are restricted to ascii?
  • paregorios ducks chrislilley's cudgel
  • chrislilley waves the Unicode stick
  • paregorios: chrislilley: no, I mistyped
  • paregorios: for bug #238 I must *exclude* various types of punctuation
  • paregorios: leaving everything else legal
  • chrislilley looks happier
  • paregorios would like to move on to bug #239 before he gets in further trouble

Issue bug #239

  • sgillies: ISSUE: bug #239
  • chrislilley: are people going to want different transliteration schemes?
  • hcayless: I think as long as you document what scheme you're using, it'd be fine
  • paregorios has been operating under the assumption that there would be only one
  • paregorios: per language/script combination
  • chrislilley: seems there are two options
  • chrislilley: one is to disable editing and autogenerate the transliteration
  • chrislilley: the other is to enable editing, but pre-fill with a suggested transliteration
  • paregorios: yes
  • paregorios: the current data employs a single, uniform transliteration scheme for classical Greek
  • paregorios: with pleiades, I would like to shift the focus to the actual orthography in the original languages/scripts
  • chrislilley considers waving the etruscan stick
  • paregorios asks that the Etruscan issue be tabled for about 5 minutes
  • chrislilley: +1 to actual orthography
  • bdturner: re: uniform transliteration - presumably into English language? What of a German transliteration ... or worse... Canadian
  • paregorios: not into English language
  • paregorios: into Roman characters
  • sgillies hoists etruscan cinary urn
  • bdturner: check
  • paregorios: you're thinking of things like the heinous Pauly practice of slapping a German case ending on an otherwise Greek name
  • paregorios would call that a "Germanized" name
  • paregorios: i.e., *not* the ancient name itself
  • paregorios: there are a couple of reasons, in my view, for doing transliterations:
  • paregorios: 1. simple sorting
  • paregorios: 2. user familiarity (helps users who don't have the original language)
  • chrislilley: I'm wondering about the capricious choice of b, p, t for transliterating Iberic, depending on what point someone wants to make with their etymological analysis
  • chrislilley: same in latin for u and v of course
  • paregorios: the managing editors, with community consultation, will have to undertake the specifications for what can appear in both attestedName and transliteratedName
  • paregorios: on a language/script by language/script basis
  • paregorios: at present, we only allow
  • paregorios: grc, la, grc-Latn and la-Grek
  • hcayless: I think you're better off with one scheme where possible, and auto-converting
  • chrislilley: "at present" - what do you plan to allow later?
  • paregorios: the legacy data sets an existing transliteration practice for those four
  • paregorios: what to allow later is also for community discussion and eventual sanction (or not) by the managing editors
  • paregorios: I'm about to start a list discussion on WorkFlowStories
  • paregorios: I will ask community members to contribute short descriptions of example additions/modifications/corrections they'd like to make to Pleiades data
  • paregorios: I hope that those who are carrying a torch for other ancient language/script combinations will surface the issue in that context
  • paregorios: we'll then prioritize and categorize the stories, generate tickets and milestones and move out
  • paregorios: hcayless: that has been my assumption
  • chrislilley shelves his torch for now
  • bdturner: count me into auto-converting
  • bdturner likes it when things are done for him
  • paregorios: chrislilley: for languages closely related in space, time, cultural or linguistic terms to Greek and Latin, I don't think
  • paregorios: there will be much trouble adding support quickly
  • paregorios: so long as they have a complete unicode subrange and there is a recognized transliteration system
  • paregorios: adding support for those that don't meet that set of criteria will require more study
  • paregorios: and coding
  • paregorios: getting a mechanism in place for automating transliteration (the purpose of this bug) is a prerequisite IMO
  • paregorios: I intend to implement the mechanism in a way that is language/script aware (on the basis of user input) and readily extensible
  • paregorios: thanks
  • chrislilley: did the question of editable transliterations get resolved?
  • paregorios: hcayless and I think that they should not be editable
  • paregorios: bdturner too, no?
  • bdturner: yes...
  • chrislilley: hmm
  • chrislilley: I foresee complaints when its not the transliteration the user expects
  • bdturner: but I recognize Chris' problem ... especially if we intend to be worldwide
  • chrislilley: but it will give you more consistency for the common cases
  • hcayless: I can imagine that for some scripts, editability might need to be turned on...
  • paregorios: chrislilley: would a "report erroneous transliteration" bug/link help?
  • chrislilley: yes
  • chrislilley: thanks
  • paregorios: hcayless: I suspect you're right
  • hcayless: but for Greek at least I'd argue for picking one
  • paregorios: there may be some lang/script combos for which a deterministic conversion from the written to a standard/scholarly transliteration (or representation) scheme
  • bdturner: so... normally we will have autoconvert... but with the option of a user to override the automated and add their own transliteration?
  • chrislilley: that sounds good
  • paregorios: may be problematic ... a choice between options may be predicated upon an "understanding" of what's meant by characters
  • bdturner: well code in a block so they can't add the @ sign
  • sgillies is still here, listening quietly
  • paregorios fears that there will be pedants who refuse to comply with common practice
  • hcayless: I would not make override an option
  • bdturner: oh ... there will be... no matter what we do
  • paregorios: and will therefore insist on modifying a perfectly compliant transliteration to fit their idiosyncratic ideals
  • hcayless: unless there are scripts which have problems being auto-transliterated
  • hcayless: and only in those cases
  • paregorios: hcayless: so the option is only surfaced for lang/scripts that site policy wants it surfaced for?
  • hcayless: that's what I'd suggest
  • paregorios: otherwise, you have to content yourself with a "report error" link that allows you to lambaste the managing editors in extended prose
  • bdturner: but how will we know what those are?
  • paregorios: two ways:
  • paregorios: 1. the managing editors say so (or not) on the basis of their best judgment and consultation
  • paregorios: 2. the managing editors reconsider an earlier decision on the basis of the amount of hate mail they're getting
  • paregorios: (i.e., the error rate reported by the community)
  • paregorios: maybe the link is: flag transliteration as bad (and you have the option of attaching a raging comment if you want)
  • bdturner: or the managing editor ignores the complaint and gets a new email :)
  • paregorios: how we decide to go on this is pregnant with implications for future decisions of the same class
  • bdturner: yeah... we're basically deciding what we'll allow the user to do
  • bdturner: Lincoln: can please some of the people.......??
  • paregorios: my concern in this context is to minimize unnecessary and potentially workflow-clogging and search-frustrating churn while still addressing needed flexibility
  • sgillies: paregorios: is a wider discussion needed to move on the ticket?
  • paregorios: this probably needs airing at the community level
  • sgillies looks ahead to 269
  • paregorios: bug #239 does not block anything
  • paregorios: ACTION: paregorios to discuss bug #239 with community
  • paregorios: ok?
  • sgillies: cool
  • bdturner: yes....
  • paregorios: chrislilley?
  • chrislilley: ok
  • bdturner: absolutely

Issue bug #269

  • paregorios: ISSUE: bug #269
  • sgillies: done :)
  • paregorios: :)
  • paregorios: mark it so
  • paregorios: and lead us onward

Issue bug #277

  • sgillies: ISSUE: bug #277
  • sgillies: i've accepted

Issue bug #282

  • sgillies: ISSUE: bug #282
  • paregorios: I've accepted bug #282
  • sgillies: i wonder if Membrane or other new membership products provide this?
  • sgillies: worth a look
  • paregorios: I think there's a standard way to put some content in the portal that gets shown there
  • paregorios: it'll be the same for all members (probably translatable with LinguaPlone in place, but that's down the road)
  • paregorios: but I'll take a quick look so we know
  • sgillies: yes

Issue bug #284

  • sgillies: ISSUE: bug #284
  • sgillies: meaty
  • paregorios: point is: should we maintain atlas practice of subaudibilizing (at the top label-level) ethnic names when there are attested geographic names
  • paregorios: saying "Alabama" for our title for the place, not "Alabama/Alabamian"
  • sgillies: i agree
  • paregorios: only using the ethnic for a place title when there is no geographic
  • paregorios: I think modifying the code is pretty easy ... I looked at it before I wrote the ticket
  • bdturner: +1
  • paregorios: so I"m still happy to accept this one too
  • paregorios: unless you think I'm too heavily burdened ;)
  • sgillies: careful management of placeful associations should prevent this from happening
  • paregorios: explain
  • bdturner: though ethnicities without geographic references should be in a separate category methinks
  • paregorios: those are just names
  • chrislilley: and they are rarely points
  • sgillies: yes, what chrislilley said
  • sgillies: ethnic names will be associated with regions (when we add them to our system)
  • paregorios: the locations associated with ethnic names are the (polygonal) extents of the range or habitation or territory of the people known by that name
  • chrislilley: I can think of plenty of maps with ethnicities strewn around to roughly indicate areas
  • chrislilley: eg 'germanic tribes' maps
  • paregorios: BAtlas has them by the legion
  • paregorios: I don't think the above discussion of ethnicities precludes implementing the proposed solution for bug #284
  • sgillies: i agree with you
  • chrislilley: i wasn't disagreeing
  • paregorios: understood

Issue bug #286

  • sgillies: ISSUE: bug #286
  • sgillies: bug #286 is your'n
  • paregorios: I've accepted bug #284
  • paregorios: this won't get done this milestone, but ...
  • sgillies: defer 284 then?
  • paregorios: let's revisit next friday

Issue bug #287

  • sgillies: ISSUE: bug #287
  • sgillies: looks good

Issue bug #289

  • sgillies: ISSUE: bug #289
  • sgillies: i'll accept, and we'll try this out on the pleiades-dev site for a while
  • paregorios: ACTION: paregorios to engage community in describing (and translating) vocabulary terms
  • paregorios: +1

Issue bug #287

  • paregorios: ISSUE: bug #287
  • paregorios: I've accepted

Issue bug #290

  • sgillies: ISSUE: bug #290
  • sgillies: same there
  • sgillies: experiment with performance on the dev site
  • paregorios: +1

Issue bug #291

  • paregorios: ISSUE: bug #291
  • sgillies: agreed. we're now indexing the vocab key and captions
  • sgillies: accepted
  • paregorios: right and users no longer see the keys in the view s
  • paregorios: so they don't need to see them in the help

Issue bug #292

  • paregorios: ISSUE: bug #292
  • sgillies: accepted

Issue bug #288

  • paregorios: ISSUE: bug #288
  • paregorios: that's a css thing
  • paregorios: accepted
  • sgillies: i'll look into that
  • paregorios: oh ok
  • chrislilley: beware relative positioning
  • sgillies: that's weird
  • paregorios: I suspect it's classes that are (mis/re)used
  • paregorios: inherited from plone
  • paregorios: and something I did in trying to play with our border colors in the customized bits above
  • paregorios: do some poking around with firebug
  • paregorios: thanks for all the great feedback!
  • paregorios: this was very productive