Let's document, as orderly as possible, the justification for putting in development time for this dynamic schedule. 


The value to the user is same

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 (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.  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) 
  • No labels

2 Comments

  1. Anonymous

    7/13, JimD:

    I would like to add a question that might help clarify this concern taken from the "Cons":

    "Concern: falling into temptation to make the calendar cluttered with more than Wednesday Schedule whereas that site is for new prospects, not members."

    Possible/Sample sub-team clutter:

    Are we getting a little ahead of ourselves?  Let me explain what I mean.  If we start with the schedule/calendar with only the general meeting.   We can then later add a schedule/calendar for each of the sub-teams (Web, DevOps, QA, etc) later.  When a user select the sub-team from the Nav bar or scrolls to it they can see the schedule/calendar for that sub-team.  Yes, There is a danger that a new person would attend the sub-team before attending the general meeting.  I really don't see this as a big problem.  The sub-teams can deal with that issue if it should take place.

    Possible/Sample General clutter:

    There is a webinar that all of TSSG might be interested in.  How to lightly integrate LinkedIn-Outlook-OneNote so that it can be used in your job search.


  2. Anonymous

    7/13, JimD:

    I am sorry but I don't understand what is meat by "Venue SSOT page".

    Is this the page → Venues

    I suggest when you reference a page yo include a link to the page.