I don’t know how others feel about it, but I fear he would be pulled off reading this whole conversation we’ve been having “in his back”. Instead we should write something more constructed, benevolent, so that he feels invited to think about it and share his effort. For me this is a preliminary work, where we draft ideas. Coming up with some more constructed text would probably be helpful.
That said, I’m open to invite him here as well if you think my fears are inappropriate.
Not yet. I was reminded as they’ve come up along with demosphere sometimes. But also independent of that barrikade.info, more via our swiss/german connections, has been mentioned - and if I understand we could be meeting some of them in october.
Sounds sensible, perhaps just build something simple, and start another discussion on this discourse.
Hum, well my impression is that its not cool to work on their back, and inviting them as soon as possible iis the most honest way to go, but only if people think its a nice and productive way to go, if not I do not think it is crucial.
I have already been stating my concern on framacolibri forum and had no response…
They will still have access to this discussion. It’s just that it might not feel welcoming to them. As we seem to agree on the need to
we already have a common ground to share with the Mobilizon team without them having to go through “historical” conversation starters.
My 0.02€
Here’s a draft topic to invite @tcit, the lead developer of Mobilizon, to the discussion. Hopefully, this discussion would eventually move to Mobilizon’s own Discourse. Please “like” if you agree to the contents, edit or comment if you see better ways…
Continuing the discussion from About mobilizon:
Dear Mobilizon 
So far the developers of other free software projects related to event management identified
Following the huge success of Peertube, Mobilizon benefits from a strong sympathy from the free software community. Nevertheless, where Peertube was creating something where nothing existed before, Mobilizon is tackling a problem space where a variety of existing solutions flourished.
I hope that Framasoft can lead the way to provide inclusive solutions to event management that will benefit to all existing projects and not put them and their communities at risk. It was a bit surprising to find out that many of these existing solution providers were not in contact with each other, hence this conversation!
iCal is a great pile of… interestingly designed materials, with some shortcomings. I believe the creation of Mobilizon to be the right opportunity to address these shortcomings and help standardize ways to exchange event data reliably in the foreseeable future.
Like most complex designs, this should emerge from a collective work where all parties can participate, rather than a hero hacker solving all for all. Hence this conversation.
Some functionality proposed in the crowdfunding campaign, especially in the higher bids, have questionable intention or utility. Some think they’re inappropriate – or inappropriately named (e.g., “multiple identities”), and present the risk of coupling such extra functionality to the actually required bricks for proper interoperability. We want to ensure the development of Mobilizon will facilitate the simplest possible ways to work with events. Hence this conversation.
We’ve never before gathered across free software projects in the same (or similar) problem space of event management, so hopefully it’s a welcoming working group in the making.
A few good starting points, but I guess you can easily find them:
@marcel, if you need assistance or funding, I’ll be happy to help.
@tcit, I would like your input as Mobilizon developer regarding the fact that a number of existing activist calendar and eventing systems represented here by their developers may be interested in ActivityPub support and interoperability with Mobilizon, but are worried that Mobilizon is going its way without regard for what is already there. We have brought everyone together to envision a way to move along, not separately.
When I see the responses so far to Avoir plusieurs identités protège vraiment? - Mobilizon - Framacolibri (in French), I see a lack of understanding of what is at stake. Since this discussion on “multiple identities” here seemed to come to the idea that this is quite far from event management and possibility mistaken, it would be interesting to read from you what’s your position with regard to existing event management alternatives such as Radar, Demosphere, and others, and your will to collaborate with these software – I note that you have some presence on SocialHub which is the right place for discussing ActivityPub implementations, but I’m more concerned, as part of Petites Singularités, that free software developments in the same field would actually collaborate where feasible.
Since @tcit is busy coding, he proposed to invite @Pouhiou from the Framasoft team to pursue the discussion. Welcome @Pouhiou, and sorry for the ton of reading!
Hello here !
Thank you for having me, and I’m gonna give you a long read, too, sorry about that 
.
Hi, I’m Pouhiou, employed as a Community Outreach Coordinator by Framasoft
I’m not a dev so I won’t interfere on technical issues here
The point of my presence is to answer to all the other points (so @tcit can save his time here to contribute on technical issues)
I want us all to start this contribution on the same basis, so I’m here to share about what we did/did not do, what we will/will not do with candor, trust and transparency
Framasoft works as a collective: I might report our exchanges to members of our association (that will respect any privacy you ask from us)
I choose to pile on this topic so you’ll be able to extract anything you think relevant in the about Mobilizon thread ps.zoethical dot org/t/about-mobilizon/2731.
I’ll try to divide each point and number them for more clarity.
I read here a lot of care and attention to make us feel welcomed, not overwhelmed and not “being talked behind our back”. Thank you all for that, it’s very heart-warming.
According to my experience, saying that PeerTube was “creating something where nothing existed before” is untrue. Before starting on PeerTube, we talked with the teams of MediaSPIP, MediaGoblin (that were already thinking about integrating ActivityPub mediagoblin dot org/news/ ), and we even looked at PopCornTime!
We have also been asked to justify ourselves for not promoting and contributing to d.tube or Steem.it, or for not using IFPS or even XMPP.
I feel that there is an asumption that Framasoft didn’t talk with or didn’t know about other solutions for publishing events and group organization. Before conceiving Mobilizon we did our homework. We wanted to contribute to a software:
that is open to contribution, scalable, and would not have a huge technical debt
that could be open to become federated by implementing ActivityPub Protocol
with an economic model that isn’t compatible with surveillance Capitalism
whitch community would be open to be user-centric
We went around and saw a lot of solutions, we talked with a lot of people (I talked with Demosphere people from Toulouse during an Alternatiba event, and @tcit talked with a Demosphere activist from Liege, and we agreed that with a 10 years old php, and a code that wasn’t on a forge, it would be very difficult to start from it). We also talked (and are still talking) with OpenAgenda people, mainly about standards.
We concluded that there wasn’t a software meeting our requirements (there was GetTogether, but when we went and talked with them, we weren’t on the same page about the core audience and the importance of UX, and their views on potentials economic models didn’t suit us at all).
Actually, we still talk with a lot of people: 3 weeks ago, in an activists conference in Toulouse, I went to participate to an exchange with the coders of Nexxo (who formerly worked on the Communecter project), Transiscope (that aggregate data), and La Ligne Jaune to see how we could work on interoperability (through standards, protocols and even through databases, but that was where I couldn’t follow ).
When I read
I want to ask: who is this “you” you’re talking about? Who are your users (or the people you want to make a software for)? How do you know their needs and uses? How do you separate your use-bias (we all have ours, no blame from me!) from their use-case?
We asked a UX designer to help us with that, and please trust that Marie-Cécile Paccard did the job: she went and met with LGBT+ communities, Eco-activists movements, and led lots of interviews before we worked with her on such a feature.
But I think it comes from misunderstandings. First, Mobilizon is not a calendar software. We want it to be an alternative to MeetUp, or to ̷̑͜F̸͛̿͜á̴̜͍k̶̡̺̃̈́e̵̲̬̎b̶̹̄̏o̵̖̾͘o̶͘ͅz̴͉̺̈́̀ “Events + Groups + Pages”. Then, the core audience of Mobilizon is not the civil-desobedient-activist who has already taken steps for their privacy. We feel Mobilizon is made for people who wants to organize/participate to a climate march or a “movie+debate” night, and would want to stop using ̷̑͜F̸͛̿͜á̴̜͍k̶̡̺̃̈́e̵̲̬̎b̶̹̄̏o̵̖̾͘o̶͘ͅz̴͉̺̈́̀/MeetUp to do so.
Please educate me. If we need to change something we promised to the people that funded Mobilizon joinmobilizon dot org/en/, I need to be able to understand so I can explain to them. When I read “harm” and “put at risk”, I feel really alarmed and anxious.
If it’s a way to underline the importance of the issue to you, that’s fine (I define myself as a Drama-Queen, I won’t judge). But if we have an oversight on how Mobilizon will create human suffering, I need to understand that urgently.
That is really important and our entire team is adamant on this point. We are not a big software company. We are not here to lead your fights even though we share them. Actually, please consider that we won’t be able to do a single thing more that what we announced.
Framasoft has done a lot of things over the last few years. So much so that we now feel the need to close down services to keep our human-scale integrity. We’ve had burns out among our members (including mine) and we will do anything to protect ourselves from injunctions and responsibilities that would eventually lead to more human suffering.
This almost is a trigger to us. iCal is a shit-show and Mobilizon, through ActivityPub, is an opportunity to change that? Great, but that’s your fight, so that will be done on your energy, we don’t have any to spare, we’re truly sorry about that.
There is a need for more interoperability between event-management softwares and Mobilizon is the opportunity to share standards and ActivityPub tips? Of course! But please consider that we will only do our best, don’t put expectations on our shoulders, or they will break and we won’t let that happen ;).
We have promised, during a crowdfunding, to publish a V1 for the 1st semester of 2020. All the energy we have for Mobilizon will go to fullfill this commitment, until it’s done. “All the energy” means one (it bears repeating : 1!) almost-full time-dev, and some colleagues who try to lessen his burden by answering anyone who wants “just to talk” with the team.
So this is a line we won’t cross: we won’t take the lead on anything, nor accept it in any way. If you want help with your fights, let’s talk in the 2nd half of 2020. If you have urgent concerns, we will talk as much as we can, but won’t be able to do the work for you.
I’m really happy that this discussion isn’t lead or hosted by Framasoft, because it’s not about Mobilizon, it’s must larger than that, it’s about interoperability between event-publishing softwares (please consider opening the category to the public for transparency).
Framasoft is seen as more powerful than we are. To see what we are, we have this data-visualization. We were in the right time on the right place issue, data-centralization. We worked our asses off, developed an approach that worked, and people started to follow us. We are grateful for and humbled by their trust. But we don’t have super powers, and we don’t want them !
Now, there are 35 of us and our services get 500-800 000 users/months (rough and low estimate). It is way too much. We are currently in the process to decentralize this responsibility onto collectives, therefore we don’t want to take more responsibilities such as leading the way to perfect interoperability.
That’s all for me, that is a lot to take in (fortunately p.s. have a meeting with Pyg in a month), but I hope we’ll now be on the same basis.
Welcome @Pouhiou, good to have you here. Thank you for taking the time.
It seems that you missed @marcel, the developer of Demosphere. And I didn’t see a mention of @ekes, the developer of Radar. This is part of why we’re here together: we think there’s room for improvement in the communication among teams who are serving communities to help them organize their events together.
I think we’re all on the same when I say that disruption is not a positive word, and that cooperation trumps markets.
Great. I think this is the way. Here is how I envision the situation: both Radar and Demosphere (and Dudle, etc., there are certainly others) have existing communities that rely on them for getting together. They have been developing concepts, usage, and privacy-aware ways to exchange event data. The prospect of Mobilizon, for all these existing communities, is to extend their capabilities towards a standardized way of exchanging event data over ActivityPub, which is what Thomas is working on: here, this step is important to make collectively; with the experience of PeerTube, we already know that Mobilizon will impose a standard on the rest of us, and will de facto define what is an event and how it is shared. Here we want to ensure that such a definition is minimal enough so that others can easily adopt it, complete enough so that all existing use-cases are covered, and compatible enough so that it does not break what already exists – or does so in a concerted way.
Well, when you’re talking about identity online, there is a very clear technical meaning for it, especially when combined with activists. I have nothing against a feature that enables someone to segregate different parts of their life, I think it’s great: but it’s not about identity per se, more like aspects, or facets of one’s focus: to me it sounds like “separate event feeds”, more filters than identities.
I don’t know how far these multiple identities are conceived in terms of identity (e.g., are they linked to a single email address, or are they each linked to a different email address?) but it seems to me there’s a confusion about identity and profile (or facets) – for lack of a better word, but definitely, “identity” is not the right term here, according to 30+ years of technical literature on the topic.
To be clear: multiple identities is not the topic of our conversation, although I would certainly feel better if the term was changed to something less critical that actually describes the intent rather than the appearance.
What is at stake is the continuity of an ecosystem on the one hand, and on the other hand the demonstration of a capacity to walk along a path of emancipation, which is how I understand Contributopia.
One important thing to realize is that the opinionated choices made by Framasoft for Mobilizon have potential consequences on how other developers perceive what an Event is and how it is encoded. Of course, the ActivityStreams vocabulary already defines this a bit, but there’s no implementation that actually makes sense. We’ve seen with Mastodon that keeping on the ActivityPub track may be difficult: the main implementation tends to influence the rest away from the protocol itself (see Mastodon API for most “internal” stuff, Mastodon to Mastodon, that avoids using the actual AP client protocol for example.)
E.g., if the user-centric approach to Events commands that an application should disclose a Person actor rather than an Application actor when submitting events to Mobilizon, that would certainly become problematic for other implementations that do not have, nor want to concept of users attached to events. Still, as far as the Event itself is concerned, there’s no reasons to assume such a link between Person and Event. This example is one of many that shows that among all possible ActivityPub implementations of Events and Places, some may be compossible with the existing ecosystem, and others not.
Hi @Pouhiou I am very happy to see you here I will try to respond to this in different steps, I am sorry if you feel accused of anything, this is not the goal here, but the goal is to work together, obviously without adding any burden on framasoft.
As said already, every project invited here have their own community the goal here is to use the posssibilities of activity pub, in a way that can help exchange between different projects so that existing projects do not become isolated.
This is very clear, and our goal here is not to put in question the choice of mobilizon, or to ask you to contribute to anything other then your project. The purpose of this conversation is to organize together so we collaborate.
I think we understand this very well, the issue is not to for you to do anything more, and we did not ask you to lead anything, I feel that in respect of the work that all the people engaged in this conversation are currently doing it would only be fair be to respond to the technical points that are being discussed here.
In this case the only way to go is to converse with others, collaboration is the only antidote to power accumulation.
heart
natacha
If everyone else is happy with this, It’s fine with me.
Hi,
I’m traveling at the moment, so just a quick note to say I’ve had a read and will feed back more if it makes sense when I have time.
One thing that strikes me is I don’t think there is a one-size fits all solution here. There are quirks in radar specifically because it fits it’s demographic particular set of groups and their activities. The most strong of these is that the individuals aren’t visible, it’s groups that organise things, and generally the last thing they want to do is present individuals. Our API and activitypub will not, just can’t, have individuals as the actors in that way. The actors have to be groups. Another is that there are also different types of groups that curate different lists of events. There are many more things like this built in; recently we’ve been in discussion with a group in a city that keeps a generally offline calendar about ways to make stuff public without disclosing all details, certainly locations, but still giving ideas of groups. It’s all that sort of thing that fits by activist communities.
That in mind we’ve always been highly interested in working out ways of interoperability between different calendars - in a practical and hands-on sense. It’s required lots of communication between groups, and multiple different methods of working (social and technical). ActivityPub could simplify this a bit - but it’s not going to get rid of the requirement to tweak systems based on requirements of other groups from working through what can and can’t be done (and wants and doesn’t want).
Sorry bit rushed… I’ll try and keep and eye on the discussion.
It’s not a miss: we talked with the demosphere community. With all due respect to @marcel, we don’t think the developers’ position as the alpha and omega of a free software existance, so we didn’t feel the need to talk together. We took a look at the code, talked with some members, and thought that Demosphere’s code wasn’t the right fit for Mobilizon.
And yes, when we have already started on our development, we don’t usually go and start a conversation (except when we come and look for information) because we already are overwhelmed by things to do and people wanting to talk with us. I’m not saying this is ideal, but this is usually how it goes in free-libre project: we all seldom have time to spare contacting other just to get to know each-other and making collective decisions (you know how it goes!).
You are hosting such a conversation (and thank you again for that), and we are open to talk, within the time and energy that we have.
Indeed! That’s why I think this should be an open conversation: I see a lot of teams missing (just in my first post: OpenAgenda[1], GetTogether, Communecter, Nexxo, La Ligne Jaune, Transiscope, plus L’Agenda du Libre, System-d[1], and the platform under construction by La Nef, Enercoop and Mobicoop).
[1] Not Free-Libre softwares, but with open data and values that can fit, depending on how open you want this collective conversation to be.
Please note that GetTogether is also working on this exact issue.
BTW, Framasoft is not creating a new standard, not event de facto, it would be presumptuous to say otherwise (plus, there is an XKCD strip about that ).
This is where I strongly disagree. You give Framasoft way more importance than what we really have (part of my job is to watch and assess our impact, and be sure that we happily eat humble pie every day).
Mobilizon still have the ability to spectacularly fail.
We will not impose a standard, we won’t even pioneer it alone (again : GetTogether was working on it before we started ).
I still agree that it’s better if our way of using standards comes from a collective exchange, of course! But please, let’s calm down on the stakes, there is plenty of room for experimentation, mistakes, and changing minds.
And you know Framasoft, you know that if we go a way and launch Mobilizon with choices that proves to be unsatisfying, we will be open to change and rectify them. Nothing is being set in stone here!
OK! If the term is the problem, it’s an easy fix, we will see if we can change it and how (I, for one, wanted to call them masks as in “social masks”).
And I understand, now, this was not the topic that was of importance to you. Thank you for your explanations.
I understand and I do agree, really.
Do you agree that those consequences will not be dramatic for one (Framasoft is not going to influence the future of the web with its opiniated choices), and that in any case they will be reversible?
Do you also agree that Framasoft is entitled to have its opinions about software making? (keeping in mind, of course, that we care about others, too)
I do not, it’s really OK, I’m fine, actually (but thanks for your concern) and I’m really sorry if my post made you feel I was under stress because I’m not.
I just wanted to straighten the facts:
I knew and I respect that. That wasn’t my point.
My point was even though you have a community, as a lead-dev, did you take time to know them? To learn about their needs, their uses? Did you stop and thought about who you would like to see using your software what you could do to ease their use and their life?
I have been in the free-software community long enough to know very few devs make such an effort. And I get it, really: it is hard enough to code and create a software, having a vision for it is a hole other job (a Designers’ one, actually).
But it’s one of Contributopia’s topics: we believe that Free Software needs to be less technical and more user-centric, hence easing collaborations between designers and devs for a real vision behind software.
I am starting to feel that our user-centric approach might be part of the problem here. If that is the case, we may have to agree to disagree. If at one point the situation forces us to choose between users or the devs community, we will choose users.
Please note that our users (who are, in a nutshell, ̷̑͜F̸͛̿͜á̴̜͍k̶̡̺̃̈́e̵̲̬̎b̶̹̄̏o̵̖̾͘o̶͘ͅz̴͉̺̈́̀ users) are really different from Demosphere’s or Radar’s.
We do agree on this goal, and that’s a great point! (see below)
I think we also need to agree on how we share the pressure, the mental load the workload.
This is exactly why we (@pyg, @tcit and me) are here, and why we think it is important to take long hours from our work-week to have this conversation together, in english, so that all the other devs who are not here yet can keep up with it.
I really want to be clear on that. The point of my first post here wasn’t to wriggle us out of this conversation. My goal was to get us all on the same conversation , to weed out assumptions, bias and misunderstandings so when it’s time to talk technical points, all devs (@tcit included) can be efficient.
@tcit might be able to expand on that if needed, but to be clear, right now, groups aren’t coded nor implemented into Mobilizon, and we plan to work on that in 1st half of 2020.
That’s why right now “identities” (social masks, if you prefer) are, litteraly by default, the creators of events. Those “masks” are translated into persons in ActivityPub, so it’s persons who are marked as the actors of the event.
Our goal is for events to be mostly created by groups. Through guiding users by the design we’ll mainly have groups marked as actors of the events in Mobilizon’s ActivityPub.
But we also need persons to be able to me marked as actors of en event: my cousin won’t create the event “My Nieces’ Birthday Party” with a group, but with her mask/identity. And this is a use case that must be covered by Mobilizon.
As fas as I understand, having both persons and groups being possible actors of events won’t be a problem with Radar: it’s just that Mobilizon’s events whose actors are persons won’t appear on Radar, and that’s OK!
Once again, it is great to see you are hosting a conversation we couldn’t organize ourselves. We are all for a better way to standardize Events in ActivityPub so that it betters interoperability. What we expect from this conversation is:
not to be pressured nor mentally loaded by overstating the stakes and our importance ;
not to be derailed from our promises and user-centric choice ;
for it to be open to a significative number of actors (and not just the 3 of us -Demosphere, Radar and Mobilizon- however brillant and beautifull we are 
!)
some linency if we don’t abide by the collective decisions on the spot and implement them from the get-go: we need to work at our own pace.
And maybe there lies a starting point that would reassure everybody here, if we went very matter-of-factly, and gave a practical answer to the question:
What do y’all expect from Framasoft?
I understand this is complex, but still the people present here do it also, because its very necessary, and important to converse lets do our best to make it happen.
Yes we agree about freedom,
The persons from the projects you mentionned we are in contact such as @tibkat have been invited SC from Transiscope did not yet answer but we meet soon so we’ll make sure he follows. We did not invite the non free software, for obvious reasons. Please explain what you mean by system-d I only know a magazine or an init system… La ligne jaune is a Drupal site I do not know they are moving towards activity pub or anything related to event announcement, but its worth the conversation with the maintainer of la ligne jaune anyways, La nef and mobicoop I do not know they did any event announcement, I thought they did ethical banking and car pooling but maybe I’m wrong, anyways feel free to invite here who ever you want, or I can do it if you suggest persons I cannot think of.
And yes if everyone agrees we will make this conference public.
Well reversibility is not something that technology does easily, unfortunately, as far as I can think in history, I do not know any technology that has been reversed…
And yes I do think Mobilizon’s decision are of importance because, as explained the first implementation of a protocol influences what others will do, so you will receive technical feedback and different opinions on what you are doing and it is important. I still strongly think that fediverse can exist only better if we make sure we coordinate a bit.
This is exactly what we are doing here, looking at ways that people using softwares and platforms for the need of their communities are cared for. And making sure that software design is discussed among the different groups so that this vision translates into the fediverse.
Note that people using demosphere or radar often also use face de bouck, so I think more subtle analysis is needed to differentiate them. But the point here is that demosphere radar communecter etc… events already exist at least partially out from face de bouck, so this conversation is meant to make sure we share grounds on future developments.
Amazing
I understand from previous conversations that this was one of the issues mentioned, tying actors to persons or groups is limitative they could be anything really even an abstraction, an application allowing to organize the follow up of event through layered filters.
But in all cases the aim of this conversation is to develop those questions, and
I let others respond here, but instinctively I would say not much really, only understanding technical decisions why they were made and how other projects can relate to Mobilizon.
Let me start with the last question and move back to technical points…
Well, first of all, you can stop being defensive: we’re having this conversation because we admire what you’ve been doing and support it fully. When I set expectations about the importance of Mobilizon, it’s because I saw how PeerTube changed the game 
, and I think the same can happen with Mobilizon: therefore it’s important that the community works together on the prospect of moving along to interoperability using ActivityPub, in a way that works for all, with all our differences.
This is not the case. A Person is an Actor in ActivityPub, and so is a Group: both appear as a single field in the form of an URL that can be dereferenced to an object (an Actor is a subclass of an ActivityPub Object, and both a Person and a Group are also subclasses of an Actor). So it does not matter to Radar whether your Actor is a Person or a Group as long as they can dereference it to what it is.
A reason why an event posted by a Person would not appear in Radar would be because this Person is not followed by anyone on the Radar instance; there’s no reason why Radar would not be able to wrap this Person into an internal representation that appears to the system to be a Group – with the limitations that Radar would only implement what is needed to make its magic work: and so, if Mobilizon couples the Event with a Person, implementing some fields that will be required by Mobilizon to interpret what an Event is, then there would be an issue for Mobilizon to understand Activities taken by some Actor on Radar’s side; Radar would still be able to consume Events from Mobilizon, but Mobilizon would be unable to handle Group-based Events from Radar. This is where it’s important that Mobilizon does not over-determine what an Event is. I assume that an Event created by a Person in Mobilizon is only the first step, since you mentioned Groups would be supported later.
IMO, Actors are commodities: some people over at SocialHub were recently complaining that an Object cannot be followed, and that we should amend the specification to allow that use-case; I think it’s a wrong approach, as we can instead create on the consuming side an Application or Service Actor that would follow the original Actor that owns the Object to be followed, and ignore all Announces except for this specific Object of interest. Since the consumer only wants to follow this Object, it’s easy-peasy to circumvent the perceived limitation of the specification by creating a commodity Actor that implements collection filtering – which is how I understand what you call “social masks”. Maybe a way to understand “multiple identities” in practice would be to have the user have multiple Persons representing it:
This is all the difference between an understanding of ActivityStreams objects as “identities” vs. an understanding as “relations”: ActivityPub is very good at handling relations, and a Person is just another Actor, interchangeable, as much as possible, as long as the implementation actually accepts this fact, and does not try to put more there than there is. But this kind of diffraction can only happen if one stops to reflect from a static model, and embraces instead a dynamic process.
This is not “10 years old PHP”. The code has been constantly updated and even partially rewritten over the past 12 years. Demosphere and Mobilizon are entirely different projects, the only common point is that they both handle events. It is perfectly understandable that you choose to write your own code … no need to badmouth other’s code for that.
I don’t have time to answer all posts right away, but I need to apologize about
I did not mean to be hurtful and I sincerely apologize for that. My intention (that I poorly stated and translated) was to say that a 10+ year-old project, written in php (both this language and its frameworks have greatly evolved in the last decade), will have an unavoidable technical debt, and it was one of the reasons we thought it wasn’t a good fit.
Once again, I can see now how insensitive and poorly stated my phrasing was, and it really wasn’t my intention, so I apologize, @marcel.
@Pouhiou I was wondering if you realized that most of the most frequented websites on the planet are working on a php app, for example, wikipedia, or fakebooze but anyways this is unreleated.
I wish to take a stand here because on the forum we promote meaningful civil and constructive interaction. And some civil attitudes such as: Please before responding to someone, read what the person says @marcel explained that the code has been rewritten 3 times so many chances are that the technical debt has been cleared if you think not, please justify what you say, and in a general situation if criticizing someone’s work, please always try to bring a useful proposition along.
Also as a rule of thumb when bringing an excuse please do not restate what was said that was hurting thereby striking twice.
Otherwise we are very pleased to hear your contributions and hope the conversation can go along smoothly.
