Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Development/Memos/Architectural Decisions

From TYPO3Wiki
Jump to: navigation, search

Current situation

A lot of contributors add bug reports and/or reviews to deal with a certain problem within the TYPO3 core. While in general we embrace these contributions, some of them try to handle problems in a way that is not preferable from an architectural point of view. Apart from that there are a lot of tickets in forge describing more or less the same problem but lack a broader perspective or the expected behavior of the overall application.

Generating an overview

In order to make the TYPO3 CMS team more agile in the way it can respond to user feedback it is crucial to dramatically lower the amount of tickets within Forge. Quite some members of the community (inside the CMS team and outside of it) have recommended closing all Forge tickets and starting out clean. While this might seem like a reasonable idea at first, we took a look at a lot of tickets and found quite a few gems that are worth not closing - but we can’t handle them right now.

Dealing with the situation

In order to deal with the situation we need to balance both factors - manpower and the amount of tickets and reviews. Simply closing a ticket as “won’t fix now” or abandoning a review is rude to the contributor. On the other hand we need to lower the overall amount of tickets and reviews to a manageable size.

Creating Work-In-Progress Blueprints

Whenever an architect sees a review or an issue that approaches a problem from a wrong angle he/she will create a new blueprint. While creating a blueprint sounds like a very huge task the actual workload is rather small. When looking at the review or issue certain implications come to mind immediately - these should be noted down in the blueprint. So a rather short description of the problem should be sufficient to work on a certain task closely together with the contributors and the community. This way we can make sure that

  • no tasks get forgotten
  • the community is involved in solving the problem
  • the expected behavior can be shaped by teaming up development and community

Closing reviews and issues

After the blueprint has been created all reviews and issues can be closed with a reference to that blueprint. It is advised to not just paste the link to the blueprint and close the review/issue but also to give some comforting words to the contributor so he/she knows that his/her problem will be dealt with on a higher level but will not be forgotten.

Alternative

As an alternative it makes sense to work with an Epic in Forge instead. From a product owners POV dealing with huge tasks in development makes this an Epic. The benefits would be that we could immediately link all closed Issues to this Epic. All contributors can add comments to that Epic issue while the architects are in charge of keeping the issue description up to date. By staying inside the Redmine platform, we can make 100% sure that no Epics will get lost.