Versions Compared

Old Version 1

changes.mady.by.user Lora L. Bates

Saved on

compared with

New Version Current

changes.mady.by.user Lora L. Bates

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The value to the user is same

It's adding development time. 

Static Schedule is a couple minutes to maintain weekly - estimating really high @ 5m, still easy; the web team meets weekly - could be done while waiting for all to join the call. 

Dynamic:  What does this mean?  Taking the information from Confluence when it is shown to the user? (7/12,JimD)  — I think that that would be the ideal, provided that Confluence has some way to interface programmatically to retrieve the information. (7/12 - KenH)

We need to address this from a perspective - DOES THIS DEVELOPMENT BELONG IN THIS PROJECT? This specific project has been open since April 2018.

________________________

Pros - benefits of making the schedule dynamic vs. static


  • a) A non-web team member can update it. (7/12,JimD)
  • b) Currently updating redundant information → http://confluence.technologynursery.org/display/TSSG c) (7/12,JimD)
  • c) Single source of truth of schedule (7/12,JimD)
  • d) No web skills required (7/12,JimD)
  • e) This is a "Skills" sharing group - one benefit would be exposing the developers to additional development work, enhancing their skills. (KenH)
  • f) Putting the information into a computer-readable format and using that to dynamically populate the calendar would benefit in a couple ways - one source of information (Yes, Single source of truth, 7/13,JimD), eliminate the need to edit HTML table code directly (I see that as being possibly error prone.)(Yes, So that people like me don't have to learn HTML, 7/13.JimD)

Cons - downside of making the schedule dynamic 

  • a) Other area affected - Confluence, TSSG space, Venue SSOT page. Concern: falling into temptation to make the calendar cluttered with more than Wednesday Schedule whereas that site is for new prospects, not members. Perhaps, should   SHOULD a member login area be added, the dynamic format makes more sense.    (I think that this should not be something to be concerned about - if the purpose of the schedule information is for the Wednesday meetings ONLY, then it should always stay that way.  If additional calendar information is eventually added, we can implement a way to filter out the unnecessary info for the new prospect information, by structuring the API to handle it as needed. — KenH)
  • b) Adds development time.  (See item "e" above - additional development work could be valuable for building the skills of the developers. - KenH)
  • c)