mailman lists for SSEDAS-Topic-Groups

Tags: #<Tag:0x00007fd5e3cafa10>

Hello @almereyda,

is it easy to deploy a mailman-list?

We could need that for the convergence-process of the SSEDAS Partner´s Taxonomies.

I will develop a workflow how to integrate the various partners into topic lists to develop their main category items, relevant for the SSEDAS-map.

@species, would you help me on developing that process?
It is going to be quite complex at one side, and needs to be very simple and clearcut, so they understand, where they are in every step of the process, as well as understand each list they are in or are not in.

Yes, it is easy. Due to the overwhelming pile of stuff in our current Scrum, still put this discussion for now in the backlog, please.

There is also a chance we will be able to offer GroupServer after my paid intervention at OpenMediAid and learning some more postfix and zope internals.

Can you provide me with login credentials to our mailman?
Then I can do that faster - if @josef wants it to be done yesterday :wink:

For sure - but only If you create a User Story in Taiga for it - so everyone can see who is working on which stuff :slight_smile:.

No, it’s still running on private infrastructure. The Mailman instances for and are going to be suspended. A migration path to GroupServer is existing.

I wonder why these lists are so important and urgent right now?
Shouldn’t we collect these kinds of requirements together and then collectively decide and build from there? I mean, we are talking about infrastructure: it’s not going to go away very soon and there is always maintenance overhead to be considered.

cc @gandhiano

I would not say urgent, but within 2 - 3 weeks would be very good.

We will start organizing the SSEDAS categories discussion in the next month. First we start with the topical area of agriculture and food, as that is the area, that Inkota already started collecting, and we have a first taxonomy-draft to refer to.

Therefor to work in lists would be very helpful for getting that discussions

  • in manner, that is doable for the SSEDAS partners (email)
  • and a way, that prevents us from having several lists of copied send to - emailadresses

If the deployment of a mailman would be reasonably easy to do, that would be the option with least friction and good to go for the upcomming task in the process.

This is the problem:

Mailing lists have nowhere been part of the project design anywhere before. Now that they unreflectedly jump in as an idea (!) which is not (!) debated, but presented as a task (!).

What stops us from using Discourse E-Mail enabled categories, why another discussion platform?

Have you ever considered web-only workflows for the work to be done?

Is it complicating or takes a lot of time / ressources to deploy that mailman?

  • Being in coversation with just Alessa,
  • having some personal experience with 2 other people from the SSEDAS project,
  • also with respect to the number of hours, SSEDAS partners replied in the questionnaire, how many hours they want to dedicate to the category development process,

I come to the conclusion, that it is very unlikely, we would succeed with web-only workflows,

  • especially as discourse and markdown is nothing to take on easy (you remember, that I refused to actively work with discourse for several months, there were good reasons).

The lists to be installed are temporary. As I did with limesurvey, I could also use another instance to do that development work, but would prefere to have it with a list.

Hallo @almereyda short notice (I delete that afterwards),

to my writing style. I tend to highlight / bolden stuff, for easier access to the core information. Writing this here comes with the intention of giving clarity, that it is not intended as SCREAM or something, as capital letter writing, people use in forums.

By going away from the machine for a minute and coming back, I noticed, that the wrong impression could be transmitted.

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).

Weren’t we supposed to test Mailman 3, especially after the feedback (from Simon?) that Groupserver is not really working that well?

Again, bringing new issues to be done quickly, like is done with this thread, is, in my opinion, taking out the focus and energy of the team as a whole and pushing us into problem zones.

Thank you @gandhiano I can see that. What I just wonder about, noticing, that in the meeting you mentioned the grooming is part of the work the scum master and product owner (whatever that role is in this efforts, at some points being me talking to the project partner [which can also be otherwise], in some points being ?]) are doing beforehand the spring meeting.

I think also @almereyda noticed my activity and I think was quite upset at that time.

Somehow I like the 6 weeks cycle, but also notice, that it simply does not fit to realities of the complexity.

That is definitely one topic I would like to work on. There is very many non-technical people in TransforMap, that could do great work in the communication and governance groups.

I would agree with that! By stating, that the lists would be temporary, I did not mean the infrastructure that allows building the lists, but just the lists to work with the SSEDAS partners.

Basically that would be very helpful within 2 - 3 weeks to start the taxonomy development process within SSEDAS, that is a pre-requisit for the data-collection.

It can (from the timeframe) be integrated in the next sprint.

Personally I thought, that is a very quick task, that is why I asked in the beginning (also based on prior experience with gropuserver not really working, and mailman working very stable and reliable):

2 posts were merged into an existing topic: reflections on scrum implementation and practice

We are and will be hosting mailman lists at PUBLIC VOICE Lab, if that is of any help.

1 Like

Hello @rasos thank you for the offer.

I would very much apprechiate it being a domain.
SSEDAS is a quite big effort, and every piece of explenation and communication needed, can easily mutiply with the partners (30+ potential partners).

This should go to some get-active mailing list server ?

I don’t think that we should integrate partner projects infrastructure into transformap.
Any partner of SSEDAS, who wants to contribute to transformap directly should be highly welcome here.


Your memories are partly right: @Simon_Sarazin asked me to have a look at their broken Mailman 3 instance.
Today I’ve also spent time with another partner who wanted me to fix their GroupServer. After seeing Discourse, he changed his mind within, let’s say, about 5 seconds. Original quote:

Why don’t we just use Discourse, then?

You are right in your sensation that we never really formalized our publication workflow towards the common public.

I’ve tried to start a conversation but were, as usual, focussed on technical details instead of highlighting the social role this would play. Currently we are all doing almost the same, some more, some less. In the future we will see a stricter seperation between certain domains as they flourish.

Actually I believe the SSEDAS project should have its own, internal communication infrastructure? @josefkreitmayer Do you know how the SSEDAS community interacts with each other?

Despite this being an infrastructural discussion, I am keen to understand the TransforMap network itself and its relation and various degrees of contribution and commitment. Then we can see which different levels of trust we can assign to formalize small patterns of roles and collaboration.

Well, discourse is not a mailing list and even though I think it works much better than one, for a lot of people (I guess particularly those of my generation and above, who did not get in contact with the internet during the Hi5/Facebook era) IT IS different than e-mail.

I do however fully agree that we should not build additional communication channels for specific partners/projects, but rather integrate collaborating partners in the existing communication infrastructure we provide. And that at the moment would for me mean having a category in Discourse for SSEDAS.

I have often mentioned we can turn it into one.

Categories can have E-Mail-In addresses, people can subscribe to every new message of the whole forum in their profiles and more. But you are right in the sense that Discourse was meant to replace mailing lists by offering new clever patterns (E-Mail notifications only arrive if you didn’t log in for 1 day, the monthly digest if you didn’t log in at all, for example).