Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Revitalising COMCIFS

I was just inquiring of James if there was an IUCr COMCIFS meeting scheduled.  10ET on the 25th would
work for me.

John

On 8/14/21 5:47 PM, Herbert J. Bernstein wrote:
> Shouldn't we have a zoom meeting just after the IUCr meeting to discuss this and any other open
> COMCIFS issues?  I believe that the CommDat meeting is scheduled for 8am NY time on Wedneday,
> 25 August, 1 pm London Time, 2 pm Prague time, 10 pm Sydney time.   Might it be sensible for us to
> have a COMCIFS meeting a little later the same day, say 10 am NY time, 3 pm London Time, 4 pm
> Prague time, midnight Sydney time?
> 
> In general, I think the most important step we could make in revitalizing COMCIFS would be to meet
> regularly, certainly at least once a year.
> 
> For the moment the agenda could be:
>      revitalizing COMCIFS
>      report of current activities
>      ITVG
>      old business
>      new business
> 
> 
> On Sat, Aug 14, 2021 at 5:18 PM john.westbrook@rcsb.org <mailto:john.westbrook@rcsb.org> <jdwestbrook@gmail.com 
> <mailto:jdwestbrook@gmail.com>> wrote:
> 
>     Hi all,
> 
>     I agree with Herbert’s friend’s opinion that adding process and bureaucracy will have a negative impact on productivity. In my
>     view,
>     fancy standards processes are wonderful for managing large groups or well-supported and highly motivated individuals.  In contrast,
>     I believe that such approaches do little but impede the efforts of smaller groups of volunteers with only limited free cycles to
>     bring to a project.
> 
>     While the dynamics of MM dictionary development may not be representative of the overall COMCIFS development effort, we have had
>     success working with standing committees of developers and key stakeholders in particular domain areas. wwPDB team members try to
>     facilitate discussion and generally reduce the friction of moving innovation in science, technology, methodology into dictionary
>     semantics that works and plays well with the rest of the MM data ecosystem.  This work is conducted in regular virtual meetings and
>     with the help of common software development collaboration channels available on GitHub.  Discussions typically center around
>     evaluating if prototype dictionary extensions and the viability of implementing these within the most widely used software tools
>     and
>     packages.  Our focus is always on trying to achieve a standard data representation coupled with a consensus implementation that can
>     move new data into the repository.
> 
>     In our experience, the success of any dictionary development effort centrally depends on getting the key stakeholders together in
>     regular face-to-face or now virtual meetings.  As I am sure, you appreciate, nailing down semantics in almost any domain is always
>     more complicated than initially anticipated, and discussions often evolve to an unanticipated outcome.  Such discussions are
>     tedious, and in my view, inefficiently conducted in protracted e-mail exchanges.  Getting a virtual consensus on a trial set of
>     semantics in periodic zoom meetings, followed by some intervening time to develop and test prototype implementations, is the
>     process
>     that we currently find successful in the MM space.
> 
>     Best -
> 
>     John
> 
>     On 8/13/21 4:56 AM, Herbert J. Bernstein via comcifs wrote:
>      > Dear Colleagues,
>      >
>      >    James is right about the need for change, and I support his suggestions.  In
>      > addition, I would suggest taking a look at the RFC process as described in
>      >
>      > https://en.wikipedia.org/wiki/Request_for_Comments <https://en.wikipedia.org/wiki/Request_for_Comments>
>     <https://en.wikipedia.org/wiki/Request_for_Comments <https://en.wikipedia.org/wiki/Request_for_Comments>>
>      >
>      > which has been very successful in achieving some remarkable results over many
>      > decades,
>      >
>      > the ISO standardization process
>      >
>      > https://en.wikipedia.org/wiki/International_Organization_for_Standardization
>     <https://en.wikipedia.org/wiki/International_Organization_for_Standardization>
>      > <https://en.wikipedia.org/wiki/International_Organization_for_Standardization
>     <https://en.wikipedia.org/wiki/International_Organization_for_Standardization>>
>      >
>      > which has also produced many important results, but also some serious mistakes,
>      > and the IEEE Standards Association process
>      >
>      > https://en.wikipedia.org/wiki/IEEE_Standards_Association <https://en.wikipedia.org/wiki/IEEE_Standards_Association>
>     <https://en.wikipedia.org/wiki/IEEE_Standards_Association <https://en.wikipedia.org/wiki/IEEE_Standards_Association>>
>      >
>      > which fits somewhere between the two others in success of its efforts.
>      >
>      >    I have a friend who insists that it is a terrible mistake for an organization to become
>      > "process driven", and he is, of course, right.  What should drive our activities should
>      > be the effectiveness of the results we achieve, but well defined, strong processes
>      > used as a tool, not as an end in themselves, can be very helpful in achieving those
>      > results.
>      >
>      >    I look forward to this discussion.
>      >
>      >    Regards,
>      >      Herbert
>      >
>      > On Fri, Aug 13, 2021 at 1:51 AM James H via comcifs <comcifs@iucr.org <mailto:comcifs@iucr.org> <mailto:comcifs@iucr.org
>     <mailto:comcifs@iucr.org>>> wrote:
>      >
>      >     Dear COMCIFS members,
>      >
>      >     I believe it is time to assess how we do things on COMCIFS, and to take some incremental steps towards streamlining our
>      >     activities and broadening our base of dictionary contributors. To that end I've created a discussion document which you
>     can read
>      >     at https://github.com/COMCIFS/comcifs.github.io/blob/master/draft/CIF_processes_discussion.md
>     <https://github.com/COMCIFS/comcifs.github.io/blob/master/draft/CIF_processes_discussion.md>
>      >     <https://github.com/COMCIFS/comcifs.github.io/blob/master/draft/CIF_processes_discussion.md
>     <https://github.com/COMCIFS/comcifs.github.io/blob/master/draft/CIF_processes_discussion.md>>.  That document is also appended to
>      >     this email.
>      >
>      >     Please discuss. In the absence of substantial objections, I will take this as broad agreement with the document and
>     proceed on
>      >     that basis.
>      >
>      >     all the best,
>      >     James.
>      >     ==========================================================================
>      >
>      >     # Revitalising COMCIFS: Discussion
>      >
>      >     DRAFT 2021-08-13
>      >
>      >     See "Next Step" at the end for suggested next actions.
>      >
>      >     # Introduction
>      >
>      >     After a decade as COMCIFS chair I have (finally, some might say)
>      >     perceived a couple of related issues:
>      >
>      >     1. Most of the work is falling on a few people, which is unsustainable
>      >     and leads to too narrow a focus
>      >
>      >     2. Dictionary development is not keeping pace with the science
>      >
>      >     This discussion document contains some ideas for a way forward which
>      >     I'd like you all to consider and to bring your combined experience of
>      >     committees and scientists on committees to bear.
>      >
>      >     # Current situation
>      >
>      >     Formally, COMCIFS is a subcommittee of the IUCr executive. While we
>      >     are relatively minor compared to the commissions, as a result we have
>      >     a great deal of flexibility in how we organise ourselves.
>      >
>      >     COMCIFS currently operates in a relatively informal fashion. Discussions
>      >     of policy are held on the official COMCIFS mailing list. Discussions
>      >     relating to the Core dictionary are held on the core-DMG mailing list.
>      >     Technical issues, including DDLm development, are discussed either on
>      >     the DDLm mailing list or within the Github repositories.
>      >
>      >     # Suggestions for improvement
>      >
>      >     ## Suggestion 1: Document procedures and processes.
>      >
>      >     The informal way of doing things is essentially exclusionary to all
>      >     those "not in the club". In contrast, easy-to-find and clear
>      >     procedures allow new contributors to feel confident that they are
>      >     approaching a task correctly and thus lower the barriers to
>      >     contribution.
>      >
>      >     Additionally, agreed and transparent procedures reduce the possibility
>      >     of mistakes or misunderstandings. I realise that I might be sounding
>      >     (perhaps frighteningly) bureaucratic to some of you, but my plan would
>      >     be to document no more than necessary to achieve the above goals. It
>      >     is likely that most procedures would be a single page, if that, and as
>      >     you will see below I'm suggesting that the quantity of procedures
>      >     depends very much on the interest of COMCIFS in having them.
>      >
>      >     ## Suggestion 2: Technical Advisory Committee
>      >
>      >     This would be the group currently called "ddlm-group" which consults
>      >     on any changes to the foundational standards (DDLm and dREL). This
>      >     group would become responsible for the detail of implementing
>      >     procedures using Github, the IUCr website and so on.
>      >
>      >     The idea of this group is to remove the (mostly perceived) need for
>      >     COMCIFS members to be across the technical detail. Instead technical
>      >     questions/issues can be delegated to the TAC. Membership models for
>      >     the TAC can be discussed, there are many to choose from in the open
>      >     source world, e.g. Python.
>      >
>      >     ## Suggestion 3: Formally involve the relevant IUCr commissions
>      >
>      >     IUCr commissions have no formal relationship to dictionaries that
>      >     cover their topics. However, it makes no sense that, for example, the
>      >     powder diffraction commission has no expected input or responsibility
>      >     for the powder dictionary.
>      >
>      >     The IUCr executive have recently encouraged us to formalise links with
>      >     commissions. This is important, as the IUCr executive are the ones who
>      >     have the ability to hold commissions accountable for their area of
>      >     expertise in the dictionaries.
>      >
>      >     ## Suggestion 4: Lower barriers to participation
>      >
>      >     All interested parties should be able to join both COMCIFS and any
>      >     dictionary management lists that fall under our purview
>      >     automatically. If unproductive discussion due to too many voices
>      >     becomes a problem then we can revisit this.
>      >
>      >     ## Suggestion 5: Better information dissemination
>      >
>      >     An informal newsletter covering recent developments helps all parts
>      >     of the community understand what is going on without having to visit
>      >     the various places in which things are happening.
>      >
>      >     # First steps
>      >
>      >     Creating and documenting processes takes time and energy. However,
>      >     before involving the commissions these processes need to be set up. So
>      >     process number 1 is the process for producing documents (sort of like
>      >     ddl.dic is the dictionary for dictionaries). I propose the following
>      >     outline for this "procedure number 1".
>      >
>      >     ## Creating procedures: procedure number 1
>      >
>      >     The type of work that COMCIFS does is similar to the W3C and other
>      >     standards bodies. I suggest that the International Virtual Observatory
>      >     Alliance documentation standards are a good reference point
>      >     (https://www.ivoa.net/documents/DocStd/20170517/REC-DocStd-2.0-20170517.pdf
>     <https://www.ivoa.net/documents/DocStd/20170517/REC-DocStd-2.0-20170517.pdf>
>      >     <https://www.ivoa.net/documents/DocStd/20170517/REC-DocStd-2.0-20170517.pdf
>     <https://www.ivoa.net/documents/DocStd/20170517/REC-DocStd-2.0-20170517.pdf>>).
>      >     These are themselves based on the W3C documentation standards. Given
>      >     that our goals are considerably more modest than those sprawling
>      >     organisations, we can aim for considerable simplification.
>      >
>      >     The following three steps and documents should be tracked on a
>      >     website: either in the IUCr CIF area, or Github repository, or both.
>      >
>      >     ### Step 1: Proposal
>      >
>      >     A short statement outlining the nature, scope and objectives of the
>      >     procedure is submitted to the COMCIFS mailing list, either directly or
>      >     via the COMCIFS secretary or chair. A draft document may be provided
>      >     but is not necessary.
>      >
>      >     ### Step 2: Working group
>      >
>      >     If the procedure is seen as worthwhile by COMCIFS, a working group is
>      >     formed and tasked to produce a Working Draft.
>      >
>      >     ### Step 3: Approved document
>      >
>      >     The Working draft is presented to COMCIFS for feedback and approval.
>      >     Once approved, the working draft becomes an approved document.
>      >
>      >     # Other required procedures
>      >
>      >     After agreeing on something like the above process, I suggest we need
>      >     to deal with the following as well:
>      >
>      >     - Procedure for COMCIFS approval
>      >     - Procedure for adding a dictionary definition
>      >     - Procedure for creating a new dictionary
>      >
>      >     # Next step
>      >
>      >     The "Creating a procedure" proposal is discussed by COMCIFS as per
>      >     Step 1 above. If COMCIFS agrees, a working group is formed to document
>      >     the process for creating new procedures, as per Step 2 above.
>      >     --
>      >     T +61 (02) 9717 9907
>      >     F +61 (02) 9717 3145
>      >     M +61 (04) 0249 4148
>      >     _______________________________________________
>      >     comcifs mailing list
>      > comcifs@iucr.org <mailto:comcifs@iucr.org> <mailto:comcifs@iucr.org <mailto:comcifs@iucr.org>>
>      > http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs <http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs>
>     <http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs <http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs>>
>      >
>      >
>      > _______________________________________________
>      > comcifs mailing list
>      > comcifs@iucr.org <mailto:comcifs@iucr.org>
>      > http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs <http://mailman.iucr.org/cgi-bin/mailman/listinfo/comcifs>
>      >
> 
>     -- 
>     John Westbrook
>     RCSB, Protein Data Bank
>     Rutgers, The State University of New Jersey
>     Institute for Quantitative Biomedicine at Rutgers
>     174 Frelinghuysen Rd
>     Piscataway, NJ 08854-8087
>     e-mail: john.westbrook@rcsb.org <mailto:john.westbrook@rcsb.org>
>     Ph: (848) 445-4290 Fax: (732) 445-4320
> 

-- 
John Westbrook
RCSB, Protein Data Bank
Rutgers, The State University of New Jersey
Institute for Quantitative Biomedicine at Rutgers
174 Frelinghuysen Rd
Piscataway, NJ 08854-8087
e-mail: john.westbrook@rcsb.org
Ph: (848) 445-4290 Fax: (732) 445-4320

Reply to: [list | sender only]