Aperto and the HTML Prototype

Information

The problem so far was that we do not have an official contact internally and at Aperto (not a single person) to communicate layout bugfixes and changes. This is an attempt to make the work more transparent and efficient between both parties involved.

How to communicate and exchange with Aperto

  • Communication language: EN - especially when using JIRA.
  • Using JIRA issues defined in a JIRA Prototype project. Link issue to the related STK issue.
  • Important: set Due Date in the prototype issue (will be the delivery date)
    • For minor work give it at least 1 week.
    • For bundled or more complicated issues at least 2 - 3 weeks.
  • Aperto has access to GIT repository using the Aperto LDAP credential.
    ssh://git@git.magnolia-cms.com/modules/standard-templating-kit-prototype.git
    https://git.magnolia-cms.com/git/modules/standard-templating-kit-prototype.git
    

There should be no further communication needed. We report the issues, they fix it in time, we transfer it to STK, test and resolve/close the affected issues.

How to include modifications/bug fixes into STK?

For this sprint, support team will do the job with indication/help/support of Natascha D..

Who will be responsible for this in the future (central point of contact)?

Natascha D. will be the reference resource and the central point of contact.
Deputies: Christian R. and Samuel S..

Main Aperto contacts

  • Timo Wirth (css)
  • Rebecca Heinen (css)
  • Alexander Farkas (js)

JIRA Prototype project

Issue Creators: Christian R., Samuel S., Natascha D., Philipp B., Eric H.
Issue Updates: Previous list and Aperto users.

It is intended like that so issues are not created blindly. First we need to check if the problem exists in the prototype as well and also try to accumulate as many issues as possible so we create as little issues as possible for Aperto. See Issues Creation for further information.

Issues Creation

When an STK bug is identified as potentially related to the static prototype, flag this STK ticket with label css or js.

Notify/Assign this ticket to one of the possible point of contacts, preferably the main contact, who will verify the validity of your assumption. In case of a real prototype issue, we will coordinate with the maintenance/support team for the release plan, group the issues regarding the prototype and create a prototype issue linked to the STK one(s).

We will automatically sweep all STK issues with fixVersion=upcoming-release and labels css or js every 2-3 weeks or on demand if need be. So make sure that you keep the JIRA issues updated, we will not look for anything else when sweeping for possible prototype bugs.

ToDo.

75%

Task List

  1. handler

    Create a Jira project for the Prototype.

    Priority HIGH
    ehechinger
    2012-06-08
  2. handler

    Create access to Git for Aperto. Ticket:SYS-107

    Priority HIGH
    ehechinger
    2012-06-08
  3. handler

    Check the STK 2.0.4 Jira Issues labeled css/js and check if these tickets are to be solved by Aperto.

    Priority HIGH
    ndesmarais
    2012-06-08
  4. handler

    Ask an Aperto contact group email.

    Priority HIGH
    ndesmarais
    2012-06-08
  • No labels

3 Comments

  1. There's prototype component is STK jira project. Is it the intention that the new Prototype project will replace the component?

    1. Yep, If it's not an over-killer process, this will give a better visibility and task separation (one project really dedicated to the Prototype provider).
      We could use the current STK Components 'template' to link internal tickets to the new Jira prototype Project (instead of labelling the tickets with css or js). 

    2. Yes, like Eric said and also because we cannot limit the access to create issues for Aperto directly if we do it within STK. Also, one issue within the "new" prototype project might correspond to 5 MGNLSTK issues. We want to bundle up real issues and not swamp them with 5 small requests/week.