#2076 NORM Trial-3: Activity default name should include creator

[Zarro Boogs per Child]

#2076: Activity default name should include creator
--------------------------+-------------------------------------------------
  Reporter:  jfuhrer      |       Owner:  dcbw   
      Type:  enhancement  |      Status:  new    
  Priority:  normal       |   Milestone:  Trial-3
 Component:  sugar        |     Version:         
Resolution:               |    Keywords:         
  Verified:  0            |  
--------------------------+-------------------------------------------------

Comment(by Eben):

 Replying to [comment:2 smcv]:
 > (1) is a job for the individual activities. Presence Service isn't
 localized and doesn't know how to translate "Draw Activity" or indeed
 "Walter's" (possessives are different in some languages, e.g. Afrikaans
 would have "Walter se Tekenaktiwiteit"). Note that Connect does change its
 name on startup, so this is feasible.

 This is partially correct.  We want activities to be able to provide a
 default title, since they are best at knowing what is appropriate.  On the
 other hand, we also need a better defaults (eg. Sugar defaults) when the
 activities don't do any extra work on their own.  It's Sugar's job to
 populate that field automatically, and it does know the activity name, the
 username, and will of course be localized as well, which should allow it
 to do so easily.  We'd also like to add a default_title property to the
 activity.info file allowing the activity to specify their own, which Sugar
 would automatically use if present.  This string should support env vars
 so that they can insert the username, date, time, or other pieces of
 relevant info.

 > (2) would require Presence Service to track who started each activity as
 an activity property. If we'd known this feature was required 2-3 weeks
 ago, that would have been very useful. As it is, this will probably need
 another round of Salut and PS changes.

 This has been core to the mesh design since the very early days; My
 apologies for not making this clearer via the wiki or otherwise.  The
 search feature is critical.  I'll add some info about it to the
 Specifications page on the wiki when I get a chance.

 > (3) doesn't necessarily work like Eben thinks it does. Telepathy, and
 the underlying XMPP and link-local-XMPP protocols we use, doesn't
 guarantee any particular ordering when listing who's currently in a chat
 room, so for any activity that started before we joined the server, the
 participants will be in arbitrary order. While we *could* maintain a
 parallel members list specifically for OLPC, the code, protocol and
 network traffic required would probably be horrible.

 I see.  All of these designs sprung from user experience scenarios; At the
 time I had no idea that there was an existing underlying protocol being
 used.  At any rate, we want the collaborative nature of the activities to,
 for the most part, be owner agnostic (at the experience level). In light
 of that statement, I actually don't feel strongly about indicating the
 owner directly in the UI at all.  On the other hand, if we do still have
 an "owner", I'd prefer to keep the API free the particular term "owner"
 and perhaps even "creator", instead using a term like "initiator" instead.

 > Also, we don't currently support attaching a list of participants to an
 invitation. Keeping this up to date would require quite wide-ranging
 changes in both Gabble and Salut, so participant lists for invite-only
 activities are not feasible for Trial-3 or FRS, I don't think.

 This is a separate issue from the initiator, but this one I do have
 stronger feelings about.  I think that it's very important to know who is
 participating in an activity before joining it.  I do understand the
 technical difficulties that arise with this requirement, though, and so
 I'm happy to concede that it is really an enhancement for convenience, and
 not essential at this stage.

-- 
Ticket URL: <https://dev.laptop.org/ticket/2076#comment:4>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system