Personal Showcase: digital menu of a school canteen based on Jira (last part)

The last article was about technical details of the implementation for using Jira for the digital menu of a school canteen. Today's article is about some details of the configuration of Jira itself.

In the corporate environment, one of the biggest challenges is to configure Jira in a well thought-out manner so that a meaningful structure is recognizable even after years.
Many good aspects have been mentioned in an Atlassian Blog post, additionally in the last months there was added useful information for a cleaning up.

However, this was not relevant for our idea - okay, also the use of Jira for this purpose was also a bit special.

To put it on a example: Custom fields in the corporate context should be as generic as possible whenever possible.
There are good reasons for this and it is still a valid and good advice.
Duplications such as "Due Date", "Committed Due Date", "Expected Due Date" often cause problems - including headaches.

Our Jira installation was comparatively tiny at that time. This can already be seen from the fact that we were using a 10-user license. The obvious step for such scenarios would have been to use Jira for other exciting requirements and implementations.
For the specific requirement some accounts for the kitchen staff to maintain the data was necessary, alongside with an account for retrieval via API.

With regard to the permissions, the installation was also kept rather simple. However, the following was relevant:

  • the kitchen management was allowed to enter and correct data, but not delete it. After all, all data should be kept for the local authorities where we knew they would come for a visit and to check the data.
    All changes made after the data was entered were logged by Jira, this is a standard feature that most users already know ("All-"Tab or "History-"Tab).

When structuring the workflow a small detail had to be considered.

  • After the import of the menu from the canteen's cloud solution, one issue was created for each of the daily meals. The status could be named generically with "Open". Occasionally - and this special feature has far-reaching consequences - a standard recipe had to be adapted in details. This can be relevant even for a sauce that needs to be thickened with a little cream (ad hoc).
    As soon as the final composition was fixed - or at the latest, unchangeable in the oven - the information had to be recorded in Jira without any doubt. In the status "Open" all information about the dishes could be maintained - but they were not yet shown on the public display. Only by changing to the (workflow) status "Published" the food was publicly displayed together with all labels.
    Then it was clear: "what's in the oven is in" - no more changes possible!
    Some hours later the issues were finally automatically set to the status "Closed" - simply for the sake of order and clarity. Closed issues could not be changed anymore. This is also a stock feature which we happily used: https://confluence.atlassian.com/jirakb/issues-are-editable-in-closed-state-218268664.html

The workflow was identical for the meat-based menu and the vegetarian menu. However, since there was no need to cut back on custom fields or screens, we decided to create multiple screens for the different menu lines which were split as per individual Issue Types.
This made it a bit easier to leave out unnecessary information (like the type of meat) for the vegetarian menu - the information was not needed there.

An e-mail integration (neither incoming nor outgoing) was not configured.

What would we do differently today?

A: First of all, the decision today would almost certainly no longer be based on the on-premise operated solution. The expenses for operation, updates and configuration are too high based on a voluntary activity in a non-profit association.

Even back then, the cloud solution (Jira Cloud) was the preference, but the costs of 10 US dollars per month exceeded the budget. The virtual server was available and payable anyway. The annual license for Jira servers with 10 US dollars was more affordable.

The provider of the canteens cloud solution is currently working on its own implementation of a digital meal plan - bringing the solution closer to a complete "industry solution" for school canteens. As things stand today, Jira may no longer be necessary for this application.
It is also conceivable that there are now improved/suitable solutions for a digital meal plan - at that time this was not (yet) the case.

Couldn't you have programmed this yourself?

A: The strongest pro arguments for using Jira were

  • desired features almost immediately applicable (experience and platform already available)
  • stock features absolutetely sufficed
  • no significant development effort (except for connections/interfaces, mainly a few implementations via REST API)
  • mandatory features first and foremost: "revision security" available as standard

The article got a bit longer than expected but I'm happy if I am was able to transport the idea to use Jira in a creative way for a non-profit.
The project was fun and provided many opportunities to learn and improve skills.

If you have some time in spare just look around in your city where help is needed - there are a lot of opportunities. No matter if related to education or not, no matter if Jira or not - non-profits are usually open for every helping hand. Just explore and talk to your local supporters, the sum of many helping hands can change a lot.

(end)

 

0 comments

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events