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:
When structuring the workflow a small detail had to be considered.
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
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)
Daniel Ebers
System Administrator
Berlin
387 accepted answers
0 comments