It is not, but lets please keep up with the scrum workflow and build things with head and feet. Every new tool/infrastructure step we take should be well planned, thought, tested and have enough resources for its maintenance, if it is to last long and to work for the commons.
And “temporary” tools are something of the worst one can do, especially when working with partners on the distance.
This conclusion we have already reached long ago, discussed it in Berlin and I myself have years of experience in this field with NGOs and other civil society organisations.
As far as I remember we even have built up stories for working on this (assuring that web and mail and interoperable).
Unfortunately stories have been so much moved and remixed, also to another board (governance), that I can no longer easily trace the things we discussed and prioritised together. I find also problematic that our backlog has been reordered without a collective process for it and all SSEDAS related stories are now on top. @josef, please avoid doing this, the prioritisation process should be a collective exercise, especially as we are working on a commoning project. New stories that come to you should go to the BOTTOM of the backlog and only be moved when we meet for the sprint planning. I am also concerned about having a second backlog (and have expressed it before), while having only one operational team at the moment - it just brings lack of overview and increased complexity for planning.
I really would like to see us completing the scrum sprint successfully (which means marking all that we committed to do as done) and we won’t make it if we start randomly packing things inside.
Things like this:
Are just dispersing our work in the group - why would you implement infrastructure related stuff when there are other in teams working on these things and with more experience? Then of course time is missing elsewhere (e.g. communication with the community)
Remember the say, “if you want to go fast, go alone. If you want to go far, go together”. And going together is sticking to what we prioritize together, even if this only happens every 6 weeks (we can reduce the sprint length in the future, if we find it not flexible enough)
If we desperately need a user story to come in the current sprint, then we should schedule a review meeting and most probably drop something else off (unless our team velocity increases in October).