Icon Wiki

Feature Wiki

Information about planned and released features

Tabs

TC Proposal: Reorganisation of the Jour Fixe

The Jour Fixe meeting is the key instrument for decision making in the development process. Each feature of the upcoming ILIAS major release is discussed. Product manager and component maintainer finally decide upon the acceptance of a feature, after considering the opinion of the participating developers and users.

Along with the ILIAS community the number of feature requests keeps growing. In the last years the Jour Fixe meetings became a bottleneck in the development process, since the number of suggestions did not match the available time anymore.

1 Perceived problems with current format

The technical board wants to address this and other issues to increase the efficiency of the Jour Fixe meetings, in particular:
  • Meetings are generally overloaded: Feature discussions take too much time; many follow-ups are necessary and sometimes issues get lost. Too much time is spent on features that lack funding.
  • The agenda is not reliable: Community members that attend to discuss a specific feature cannot be sure, whether or not this feature will be actually be discussed in a meeting. If time-consuming issues are discussed before, a feature request may be postponed to the next meeting.
  • The quality of feature requests varies significantly: Feature requests of bad quality clog the meeting, requiring a lot of conceptual discussion. Conceptual issues should be settled beforehand.
  • Sometime important stakeholders are not available: For example colleagues stand in for component maintainers. Typically the prospective client does not participate. This minimises opportunities to quickly clarify open issues or questions.
  • It is taxing to virtually participate in the meetings: Telephone or Skype calls are impractical. In general the mixture of real and virtual meeting is challenging all participants.
  • In the community the awareness of decisions of the meetings is not high enough: Not all community members actually read the Jour Fixe minutes. This is also true for the collaboration between the Jour Fixe and the SIGs.
To tackle the problems listed above we propose the following new rules for the Jour Fixe meetings.

2 Suggestions for Meeting Management

  • A first version of the agenda MUST be published one week beforehand the meeting.
  • Agenda items SHOULD be discussed virtually in the feature wiki (feature requests), Github (pull requests) or Mantis (bug reports) in the week before the meeting.
  • The meeting MUST use a general agenda template with defined time slots. The number of the slots may vary from meeting to meeting.
  • Stakeholders SHOULD apply for time slots and agenda items up to one week before the meeting. Applications MUST be sent to the product manager, preferably directly into the "Suggestions for the Jour Fixe Agenda" data collection***.
  • Feature discussions MUST be confined to 15 or 30 minutes time slots. Up to half of the time CAN be used to present the feature, followed by a discussion. When time is up, the PM decides how to follow-up on the issue (reschedule for Jour Fixe, workshop, spend more time on discussion in current meeting, etc.).
  • If a feature discussion is expected to require more than 30 minutes community members SHOULD hand in an application for a workshop. The product manager will decide on the workshop and publish feature workshop events in the Jour Fixe.
  • The product manager quickly checks whether an application meets the criteria and sets the final agenda. The product manager SHOULD strive for allocating slots fairly to all stakeholders.
  • Component maintainer MUST read and comment on their agenda items during the week before the meeting.
  • If a feature is new and has no maintainer yet, a potential maintainer SHOULD be identified before the feature is discussed in the Jour Fixe or in a workshop.
  • At any time the PM or a service provider can be asked for help.
  • It is possible to participate JF meetings and workshops virtually. It is an open issue how to improve the current situation.

3 Suggested Jour Fixe Agenda Template

  • Start: 12:30
  • Announcement of Future Workshops/VCs/JFs (that make JF-like decisions, merely included in minutes, no discussion)
  • Maintained Versions
    • Announcement of Roadmap (merely included in minutes, no discussion)
    • Mantis Bug Reports (correct developer assignments should not be checked during the JF, only scheduled reports should be discussed). When time is up before a decision is reached, the bug is postponed to the next JF.
    • Open Pull Requests
    • Report on Continuous Integration (2 minute report, no discussion)
    • Announcement of Incomplete Implementation Information in Feature Wiki (1 minute, no discussion)
  • Break (estimated ending around 14:00)
  • Developing Upcoming Release
    • Feature Requests To Decide Upon (including proposed kitchen sink entries and features to be abandoned)
    • Development Issues (Discussions on already scheduled features).
    • Report on Lists of Suggested Features (2 minute report)
    • Report on Test Status (2 minute report)
  • Break (estimated ending around 17:00)
  • Miscellaneous: Open slots for all other topics, e.g. feature requests without maintainer, "call for maintainer", general kitchen sink issues, special topics like PHP7 status, TB issues) (no fixed slots)
  • Estimated Ending: 17:30

3.1 Handing in Bug Reports

  • The status of the bug report MUST be set to “Needs JF Decision”
  • A comment in the report should address the Jour Fixe directly and present alternative solutions.
  • If possible, the PM may decide whether an issue is a bug or not beforehand.
  • The PM estimates the time required per bug report and assigns a time slot for discussion (10 or 20 minutes) accordingly.

3.2 Handing in Pull Requests

  • Prior to discussing a pull request is to at the Jour Fixe an informal e-mail SHOULD be sent to the PM, containing the link to the PR.
  • A comment in the pull request should address the Jour Fixe directly and present alternative solutions.
  • The PM estimates the time required to discuss the PR and assigns a time slot for discussion (10 or 20 minutes) accordingly.

3.3 Handing in Applications for Feature Requests/Discussions

  • A feature wiki entry has to be created based on a (new) template. The entry MUST meet the following criteria.
    • Before handing in a feature proposal for a feature workshop:
      • The proposal MUST outline the problem the proposal tries to solve.
      • The proposal SHOULD contain a brief conceptual summary of the proposal.
      • The proposal MUST indicate the current/future maintainer of the feature.
    • Before handing in a new feature proposal (incl. abandoning features) for a Jour Fixe meeting:
      • All points listed above for feature workshops.
      • The feature proposal SHOULD be conceptually complete. It should not leave any conceptual issues open. It SHOULD be possible to make a final decision on the proposal (yes/no, selecting one of multiple alternatives).
      • The proposal MUSTcontain relevant technical information provided by the maintainer (dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues).
      • The description SHOULD list all views (screens) of ILIAS that are to be modified, removed, or introduced.
      • For each view the description SHOULD list all user interface elements that are newly introduced, modified or removed. The description SHOULD use the terminology of the kitchen sink, if possible (Button, Glyph, etc.).
      • For each element their textual appearance (labels of buttons, headings, etc.) SHOULD be provided and for interactive elements their behaviour SHOULD be described (what happens if a button is pressed).
      • To support the understanding of the feature screen mock-ups SHOULD be added.
      • If new user interface elements (elements that do not exist similarly in ILIAS) should be introduced a pull request for the new elements MUST be provided, according to guidelines of Centralizing UI-Components. If in doubt what new interface elements will be needed, a feature proposal MAY be handed in without a new UI component suggestion. However the Jour Fixe MAY request a UI proposal for a final acceptance. There also might be the possibility that existing UI elements are sufficient for the realisation of the intended functionality.
      • Maintainers MUST indicate if they support or object the request in general. Objections MUST be listed on the feature wiki page. Objections at this point do not mean that the topic will not be handled during JF.
      • The product manager SHOULD indicate if she/he supports or objects the request in general. Objections SHOULD be listed on the feature wiki page. Objections at this point do not mean that the topic will not be handled during JF.
      • The maintainer's or product manager's statement to support a feature request in general does not imply the acceptance of the feature. This is only decided in the Jour Fixe.
      • Maintainers MUST provide the metadata "Related Component/Module" and "Development Status".
    • If a feature wiki page meets the above criteria a mail is to be written to the PM applying for a feature discussion slot in the Jour Fixeor for a feature workshop. The mail SHOULD provide the following information:
      • Jour Fixe feature request slot application (incl. proposed abandoned features) / on-going development issue
        • Name of applicant
        • Envisaged Date of Jour Fixe meeting
        • URL to feature wiki entry
        • Slot length (15 or 30 minutes)
        • Name of presenter
        • Name of responsible and participating maintainer
      • Feature workshop application
        • Name of applicant
        • Date of meeting
        • Location
        • URL to feature wiki entry
        • Workshop type (1 hour VC, 2 hour VC, half day meeting, full day meeting)?
        • Name of presenter
        • Name of responsible and participating maintainer
 

4 Implementation of the Proposal

We would like to officially decide on the proposal on the Jour Fixe on 12 Sep 2016. From this day on new feature proposals for ILIAS 5.3 should use the new template and respect the new rules. The Jour Fixe on 26 Sep 2016 will be using the new agenda template. We will then evaluate the new process constantly and make alignments if things do not work out as expected.

5 Status

  • Effective from September 14, 2016
  • Approved by Jour Fixe at: JourFixe-2016-09-12
  • Implementation status: implemented completely

6 Discussion

JourFixe, ILIAS [jourfixe], Sep 12, 2016: Alexander gave an overview on the new Jour Fixe template, the suggested timeslots for new features and the Community FAQ. We highly appreciate all suggestions and would like to implement the new Jour Fixe process from now on. Matthias will set up a dedicated wiki for the Community FAQ tomorrow and add the new URL to the new feature wiki template. From Wednesday on, we will use the new template for all new feature requests.
Killing, Alexander [alex], 20 Mar 2017: Today we held a feedback workshop on our Jour Fixe procedure. The minutes are available here. I have marked all proposed changes in the article above. The JF should finally decide on the changes.
JourFixe, ILIAS [jourfixe], March 27, 2017: Alexander presented the changes discussed and decidec by the Technical Board (indicated in purple). We highly appreciate this new version.

Last edited: 27. Mar 2017, 17:32, Kunkel, Matthias [mkunkel]