MPDL AB Meeting 2008-11-27

MPDL  Restricted Access to MPDL

=Agenda=
 * Date: 27.11.2008
 * Participants: Natasa Bulatovic, Tom Endres, Michael Franke, Tobias Schraut, Wilhelm Frank,

Transformation service

 * TODO (Rike, Michael)

Invitation from SUB Göttingen for a eSciDoc workshop

 * The eSciDoc Workshop is 22(23)-01-2008
 * Michael to check with AndreasA (TextGrid).
 * Registration for textGrid
 * NBU
 * Others to check
 * Participation on WShop
 * more developers
 * MFR
 * TSC
 * TEN
 * MAH
 * NBU
 * check on needs

AB Self-reflection

 * Input from Natasa
 * 1)  new service or component design etc. has to be approved first with the AB in following manner:
 * 2) design of interfaces
 * 3) libraries, components in use
 * 4) new GUI libraries, classes etc. need to be agreed with the AB before proceeding
 * 5) new/changes in functional features that are planned for releases
 * 6) before communicating it outside feedback on feasibility before "fixing" in plan must be given from the AB
 * 7) AB should be able to give high-level estimates on efforts (person/weeks(evtl.days)) (even if there is not too much details that can be taken into consideration, simply based on experience)
 * 8) the scope of technical implementation shall be documented in the following manner
 * 9) if extending the scope - why, implications for related components, services, FIZ, GUI
 * 10) if narrowing down the scope - why, document further developments, propose timeline to full implementation
 * 11) Senior member shall make certain that the documentation for a certain service/component is ready and sufficient
 * 12) by checking the code
 * 13) by asking responsible people to put respective design into the EA
 * 14) Senior member shall make certain that code is of sufficient quality
 * 15) by checking the test cases covered and their validity of test cases (new test cases evtl. be proposed, schedule is separate issue - depending on timing and importance)
 * 16) by having random looks into code from time to time and issuing //TODO comments (JIRA tasks)
 * 17) AB shall make/revisit the list of most important topics (up to AB to define this list, one regarding technical docu is http://colab.mpdl.mpg.de/mediawiki/ESciDoc_Technical_Documentation/Wish_List)
 * 18) these topics will be transferred to each new AB meeting page on Colab as long as they are open and there is no decision
 * 19) separate pages for discussion on these topics will be linked from AB meeting pages
 * 20) AB shall be flexible enough to meet in urgent cases
 * 21) AB shall make sure that the server infrastructure is ready and available in accordance with release plans and available services/solutions
 * 22) AB shall communicate all outputs/decisions via Dev-list (providing links to colab, source-code files in repos etc.) and on Dev meetings
 * 23) AB member shall be responsible for organizing/monitoring a release process (when it comes) - depending on solution - will be decided by the AB (and all issues to be communicated within AB quickly)
 * 1) AB member shall be responsible for organizing/monitoring a release process (when it comes) - depending on solution - will be decided by the AB (and all issues to be communicated within AB quickly)

Then the design/architecture is adopted by the AB (or not)
 * Input from Michael
 * What can a senior do self dependently?
 * the senior creates the design and the architecture for his domain (together with the developers working in his domain)
 * makes sure design/code/architecture of his domain is consolidated
 * allocates the developers working in his domain


 * When shall a developer address the AB? (Threshold)


 * Should be easily measurable by developers.
 * For services:
 * When services are newly incepted (start doing design from idea, cross check with AB when design is discussion/QA ready)
 * When interfaces between components/services need to be changed
 * When new components/libraries (escidoc or third-party are/shall be introduced)

deciding...)
 * What is the general purpose of the AB? (Reporting, discussing,
 * The AB is a steering-commitee to monitor/propose
 * software design
 * software architecure
 * development process (workflow, dev. env., resources)
 * release timeline


 * Which subjects shall the AB address?
 * The AB shall decide
 * on the design of new features
 * on the architecture of new features
 * on essential changes in the existing design/architecture
 * on changes in the development process (workflow, development environment)


 * The AB shall discuss
 * technical feasibility of functional specifications
 * feature set for new releases
 * incoming design/architectural questions
 * resource issues (who can do what, propose resource/timing)
 * impact of FIZ developments to our development


 * The AB members shall report
 * on the OVERALL progress in their domain (this should be done more detailed in the dev meeting)
 * on critical or challenging issues


 * Which NOT?
 * The AB is not a working group, i.e. the AB (as a whole) does not develop design/architecture/code.


 * How are decisions made in the AB?
 * Decisions should be made by full consensus
 * If, after an elaborate discussion, there are still differing opinions, the qualified majority decides i.e. 3 members of the AB
 * How binding are decisions made in the AB?
 * Decisions of the AB are binding
 * If new circumstances occur that require a reflection/change of the decision, the AB has to decide again
 * If a decision has to be changed before the AB is able to react, the AB has to be informed as soon as possible