User:Bryan Hilderbrand/Meeting Announcement (20DEC)
Originally sent via email titled The "MediaWiki products" project: next steps" (Sun Dec 20 15:51 UTC 2020)
(Scroll to see thread)
Hi everyone,
Thanks for participating in the "kickoff meeting" (I hope we can call it that) we had on Friday. It's great that there is this level of interest in this project - obviously, if there were less interest, this would be a very different situation. And there was a lot of good discussion - for a plan with this many elements to it, there were a lot of different things to discuss, which is difficult to do with this many people in just one hour, but we did manage to cover a lot of important topics.
By the way, I'm sending this email to almost everyone who was there - there are a few people whose email addresses I don't know, though. Please forward this to anyone I missed (there may have been just two people) - and, of course, feel free to also forward this to anyone else whom you think may be interested in participating. This is not a secret project, but I just don't want to spam people who are not interested.
Here, as far as I can tell, are the issues on which there seemed to be general agreement, or at least no stated objections:
- We should keep these discussion meetings going, starting next year.
- The two main work areas for this project are (1) some mechanism for creating Docker images (or something like them) to install MediaWiki plus some set of extensions and skins, and (2) creating one or more "packages" of wiki pages for different use cases.
- Work on the two main tasks can be done in parallel, and actually pretty much independently of one another. (Either one would be quite useful on its own to have, I would think.)
- The Page Exchange extension is a reasonable mechanism for getting pages into people's wikis, at least for now. (There was definitely discussion of other approaches, but it doesn't seem like any of them are widely usable at the moment.)
- All components generated should be released as open source.
- We will use a wiki to coordinate work on this whole project, and Rich Evans will set it up.
The meeting also clarified that we would not really be "starting from scratch" on either task. For the first one, there is already Meza (https://www.mediawiki.org/wiki/Meza), which may or may not be what is needed - but it certainly seems close, at least in concept. And for the second one, there are already various consulting companies and organizations who have created data structures that could be used, in total or in part, for some of the use cases we have talked about.
That is why I am proposing the following:
- Starting in January 2021, we hold weekly meetings, alternating on these two topics - so really it would be two different bi-weekly meetings, on alternating weeks. We would pick some day of the week and some time, and that would be the day/time for both meetings, on different weeks.
- I also propose that we give this project its own name, so that it's not just called the "MediaWiki products" project - which would make it easier to talk about, and to name related things (like our meetings). Since I don't want to waste a lot of people's time trying to collectively come up with a clever name, I am hereby proposing the name "Project Canasta" for this project. I hit on this name using the clever strategy of doing web searches on "Project X" with all kinds of words for "X" until, after 30 or so attempts, I finally found one that has not been used already. :) There are a lot of "projects" out there! Let me clarify that this is *not* the name of the resulting product or product suite - if that product will even have its own name (some people want to brand it as just MediaWiki). This is strictly the name of the project to create these things. "Canasta" could be a product name on its own, but I'm pretty sure there are better names. (I would say that it's not a perfect name, because, among other things, I think it has two different pronunciations - in the English-speaking world, most people would pronounce it to sort of rhyme with "faster", while in the rest of the world I think it rhymes with "pasta". But I think that's okay, at least for a project name.)
There are obviously aspects to this whole project that are not covered by these two tasks. These include issues of branding, marketing, and governance. They also include the question of whether Page Exchange would be used as the system for installing pages, or something else. These all came up during the meeting (as would be expected), and they're all important discussions, but I personally think the highest-priority thing is just getting a system in place that works - and once that happens, it will be easier anyway to deal with these other questions. I could be wrong about these, though, and if there are some issues that keep coming up during meetings, like governance or anything else, then it probably means we should be talking about it.
This is a lot to cover here. This is my attempt at establishing and/or identifying consensus, and there may actually be a large number of points here that people disagree on. If you disagree on anything here (including the proposed project name, meeting schedule, etc.), please respond. Or if you have thoughts on the specific day/time for meetings, that would be helpful too.
-Yaron
I just want to note a few of the things:
- It looks like "Project Canasta" is the official name of this project now, given that there are no objections. And actually, people have started calling the product itself "Canasta" now as well, which is fine - and probably inevitable. (It's better than some of the previous placeholder names, like "Acme".) I just want to restate that this doesn't mean that "Canasta" will be the actual product name - I'm sure there are better names out there.
- We should have a standard date and time for these meetings. Wednesday at 4 PM UTC seems to work for everyone, in theory; although some of the Americans would prefer a later time. Europeans - how would you feel about starting, say, an hour later? Or even something like 8 PM UTC (9 PM in Western Europe)? And if anyone would prefer a day other than Wednesday, please say that as well.
- The consensus seemed to be that we should base the installation code on either Meza or the BlueSpice Docker image. (Or Lex's Dataspects installer, although seemed to be a less ideal fit for this purpose.) That's assuming that the BlueSpice image stuff can be open-sourced - if not, Meza would be the obvious candidate. In any case, it would be very good to have all the relevant people - Richard, Markus, Greg, and ideally Cindy from the WMF (they have their own Docker approach) and Daren and James from NASA - at the next meeting on this topic, two weeks from now.
-Yaron
Hi all,
thank you for the great minutes! I will join the next meetings.
Without having coordinated further with the developers, my first statement is that we at Hallo Welt! would prefer a Docker-based system, as it allows a distribution to be installed and updated quickly and platform-independently (OK, you need Docker, of course).
In addition, Docker is becoming extremely widespread right now, not least thanks to the Kubernetes container management system. I know there are open source alternatives to it as well. And there are plenty of approaches (Ansible, Meza, ….). But with Docker one would meet the needs of many hosters and large cloud services providers (Azure, Google, IBM, Red Hat ...) and ensure a corresponding spread of the system. Isn’t Wikimedia using Kubernetes as well? Spreading would be important in order to achieve something like standardization.
But this is just a quick post-filed feedback. I'd be happy to discuss this in more detail in upcoming meetings.
Maybe it would be helpful to have a look at the discussion about a Sunflower distribution in 2019 for defining a new strategy?
https://mwstake.org/mwstake/wiki/Sunflower_MediaWiki
On this page you can also find a first list of possible extensions. This would have to be fundamentally reconsidered. We have come so far that we have put together a first collection and checked who maintains which extension. But we did not get any further. Maybe this is nevertheless a base which is helpful for Canasta? Or for the coming packages discussion? We can also contribute a few extensions to BlueSpice. This would, for example, simplify the whole rights management and administration. Let’s discuss further.
Many regards!
Richard
Hi Yaron,
You wrote: “That's assuming that the BlueSpice image stuff can be open-sourced”.
Already done: nearly all BlueSpice extensions are published and can be used. (I list the exceptions right away). We have also already debranded some extensions. The only thing we will not support would be a complete fork of BlueSpice pro. ^^ But I also don't see that this is the goal, but my understanding is that it's about creating a common base and developing different packages or variants similar to the Linux world.
These extensions are not published yet:
- BlueSpiceReview and BlueSpiceReviewExtended: Here we will work on a completely new and integrated version. I can't say anything about that at the moment. But I can imagine that we will also abandon these extensions as maintainers (similar to the WYSIWGY editor) because we are reworking the architecture. But ask me about that again in half a year.
- BlueSpicePlayer: The reason why the extension has not been released yet is unknown to me.
- BlueSpiceWebDAVClientIntegration: In fact there is already a public repo "WebDAVClientIntegration", but there was no time left to do a "debranding".
- BlueSpiceWebDAVMinorSave: Ditto, but I think this could/should be merged into "WebDAV" in the medium term anyway.
- BlueSpiceFlaggedRevsConnector: There are some technical hurdles here.
- BlueSpiceUserMergeConnector: presumably this extension has simply been forgotten so far. However, the code would have to be made fit with respect to coding conventions and I18N before release.
Have I helped with that yet? Or what are you missing?
Richard
Hi Richard,
Thanks for your responses, and it's great to hear that you're planning to attend the next meetings. Some comments:
- Just to be clear, the key thing we're looking for here is not a Docker image exactly, but a *mechanism* to create Docker images (or whatever it is). So the thing we might want from BlueSpice, for this part of the project, is your code for creating the Docker image.
- Right, an actual discussion of which extensions to include makes more sense in the "products" discussion (it's quite possible that different products would include different sets of extensions).
- Thanks for linking to that "Sunflower Distribution" discussion page - very interesting, and of course it's not that different from the kinds of things we are talking about now.
- Meza uses Docker too, it turns out (along with Ansible). So it should be quite useful to discuss the specific differences in the approach, and see what makes the most sense for us.
-Yaron
No problem. We can provide the Docker scripts for BlueSpice free to kick off "Canasta”.
R