= Attendees =

* Conrad, Elaine, Eric, TomG, Greg, TomF

= Agenda =
* Review action items from 9/14 meeting
* Vijay's visit
* Beta release discussion
* Next meeting
 - [http://plato.cgl.ucsf.edu/pipermail/chimera-users/2017-August/013830.html Glycosylation depiction]
 - Who will develop mmCIF writer? [https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/752#comment:3 ticket]
 - ChimeraX on Github
 - Rotamer library license

= Discussion =
* Beta release discussion (including 9/18 minutes)
 - Why do we need a beta so soon?  Why not leave it as alpha?
  - we said we would
  - demonstrates progress, although alphas do that too
  - a beta is a milestone that shows more confidence in the functionality and stability of what we are releasing
  - it looks bad not to have a beta given the time spent in development
  - would send a message to reviewers of our R01 proposal that we have made significant progress on this project
 - What does it mean to release an API?
  - Using mechanism to be established, we label functions/attributes/properties/etc as API if we intend to support semantic versioning for them
  - Developers can use non-API items but have no guarantees that they will continue to work
  - Developers should be able to easily determine whether an item is part of “the API”
 - What consists of "the API"?  Public methods, even those without Sphinx documentation?
  - It is easier to mark items as part of the API than to mark items that are NOT part of the API
  - There are methods that should not start with underscore because they are shared among classes internally, but are still not part of “the API”
  - Tentative APIs also should not be labeled as part of the API because we may not support forward compatibility
  - We can use naming conventions (which developers may not know about, might be painful for internal development) [Answer: No, none that could be agreed on]
  - Annotation on non-API items: decorators (does not work with attributes and properties) or doc string markers (e.g., “unsettled”)
    - doc strings will work for attributes, optional arguments
    - we agree that this is a viable solution but not the one we will use
    - will need to go through source code and add everything before beta
  - Annotation on API items: decorators/doc strings
    - Developers will not see non-API items clearly marked
    - Omission of markup less detrimental
    - Less effort
    - Might leave more markup in the long run (if public API outnumbers non-API items)
    - we agree that this is a viable solution and **IS THE ONE WE WILL USE**
    - we will use doc strings rather than decorators because doc strings work for properties.
    - attributes will be documented in the class doc string
    - Marker string is "Supported API." at the beginning of the doc string
    - will need to go through source code and add everything before beta
  - Have a utility that identifies non-API items in bundles (may not be practical)
 - How much "firming up" API is needed?
  - If it’s ready, it’s ready
  - If it’s iffy, it’s not
 - Will bundles move out from core, e.g., atomic?
  - Do it before beta and there is no API change needed later
  - Most import’s will need to be changed when package is externalized
  - Toolshed images/documentation needs effort
  - Order packages based on dependency
  - Eric will try to bundle-ize core.ui after preferences
 - What are the beta APIs?  Toolshed.  Atomic.  Command…
  - The plan is to write a tutorial for a "simple" bundle supporting commands and HTML widget GUI
  - beta APIs must support everything in the tutorial
 - Release protocol for "core" bundles? (defer for now)
 - Is December a realistic target?
  - it depends whether the milestone is more important or more functionality is more important

* Need to investigate
  - Replace ctypes in atomic with Cython
* Make ChimeraX tickets viewable publicly
  - ~~Private tickets need to start private
  - ~~Alternative, make all tickets public and make UI say "don't send private data"
  - Make tickets public now and add warning later when needed
* Beta release topics
  - Meeting on Monday
  - Why do we need a beta so soon?  Why not leave it as alpha?
  - Is December a realistic target?
  - Will bundles move out from core, e.g., atomic?
  - What are the beta APIs?  Toolshed.  Atomic.  Command...
  - How much "firming up" API is needed?
  - What consists of "the API"?  Public methods, even those without Sphinx documentation?
  - Release protocol for "core" bundles?

= Action Items =
* Conrad will write bundle code tutorial
* Everyone will test save/restore v3 session files
* ~~Greg will make session file format changes
* ~~Elaine will add "no private data" to contacts.html
* ~~Eric will add "no private data" to traceback printout in log
* Conrad will make tickets publicly readable
* Conrad will continue working on ribbon tickets
* Conrad will investigate implementing the "like" operator
 - e.g., to specify polymer in atomspec
* ~~Conrad will send mail to RCSB about bad pdb.org certificate