Review “Less jQuery” changes
Hello,
removing the dependency of jQuery in django-mailman3, Postorius and maybe in Hyperkitty will allow Postorius to load faster in browsers - less data (JavaScript) is transferred from webserver to webclient, less code is parsed and interpreted by the browser. Removing the dependency on jQuery is a big change, which can be split into smaller steps. I have started with few modifications:
• https://gitlab.com/mailman/django-mailman3/-/merge_requests/334 • https://gitlab.com/mailman/django-mailman3/-/merge_requests/344 • https://gitlab.com/mailman/postorius/-/merge_requests/1045 • https://gitlab.com/mailman/postorius/-/merge_requests/1044 • https://gitlab.com/mailman/hyperkitty/-/merge_requests/688
I think as next somebody should review the above changes, e.g. try to deploy them locally and state, that the modified code is executed, while the behaviour (program logic) does not change.
Greetings // Дилян
Дилян Палаузов writes:
removing the dependency of jQuery in django-mailman3, Postorius and maybe in Hyperkitty will allow Postorius to load faster in browsers
This is true, and generally a good idea. However, it is commonly true that browsers cache this code, and users keep these pages open for a long time. To the extent you have open pages and/or cached code, the benefit is less. I don't recall hearing that page loading delay is a common issue.
The changes in your 5 MRs are quite small. I suppose the use of jQuery is quite extensive though. How much code to you expect to delete and add to completely remove the jQuery dependency from Postorius? From HyperKitty?
jQuery is a well-known idiom, and provides a lot of features. Which brings up two questions:
- Would jQuery-based code be significantly easier to maintain, eg, by new developers who don't necessarily know Mailman but do know both js and jQuery?
- Is there jQuery functionality that we might want to use that would be more complex than the code in the merge_requests you have already?
I think as next somebody should review the above changes, e.g. try to deploy them locally and state, that the modified code is executed, while the behaviour (program logic) does not change.
I'm really not qualified to do this review (especially the issue of whether there might be behavior changes). I'm not sure if Mark or Abhilash is much better able to do so, although I know Abhilash has worked on the Django apps quite a bit and probably on the js parts.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hello Stephen,
using jQuery was reasonable, when browsers have not offered document.querySelectorAll(), AJAX, fetch() functions in a consistent way [0] and the same program logic had to pe implemented differently per browser vendor. In current browsers. what jQuery offers can be implemented with DOM and direct JavaScript, (and possibly polyfills) without huge extra efforts.
- Would jQuery-based code be significantly easier to maintain, eg,by new developers who don't necessarily know Mailman but do know both js and jQuery?
I guess yes. If one knows JavaScript, the DOM and the Webbrowser interfaces I cannot think of an example which nowadays will be significantly easier to implement with jQuery compared to no jQuery. However it is quite some time since I have not done web development and even more time, since I have not worked with jQuery.
- Is there jQuery functionality that we might want to use that would be more complex than the code in the merge_requests you have already?
I do not know. Somebody said in the past that Hyperkitty uses jQuery plugins, so there things get more complicated.
How much code do you expect to delete and add to completely remove the jQuery dependency from Postorius? From HyperKitty?
git grep '\$[\(\.]' $(find -name '*.html' -o -name '*.js')
suggests that in django-mailman3 jQuery is used in approximately three places and in postorius it is used approximately on 45 places, not counting in bootstrap and jQuery itself.
But irrespective of the amount of changed lines, I think the replacement procedure will be finding a pattern how to replace one thing with another, and then doing very similar substitutions on all places, which match. So the question is probably how much patterns will be there — I do not know.
[0] https://blog.logrocket.com/why-jquery-4-good-reminder-stop-using-jquery/
Greetings // Дилян
-----Original Message----- From: Stephen J. Turnbull <steve@turnbull.jp> To: Дилян Палаузов <dpa-mailman@aegee.org> Cc: mailman-developers@python.org Subject: [Mailman-Developers] Review “Less jQuery” changes Date: 24/02/26 15:10:10
Дилян Палаузов writes:
> removing the dependency of jQuery in django-mailman3, Postorius and > maybe in Hyperkitty will allow Postorius to load faster in browsers
This is true, and generally a good idea. However, it is commonly true that browsers cache this code, and users keep these pages open for a long time. To the extent you have open pages and/or cached code, the benefit is less. I don't recall hearing that page loading delay is a common issue.
The changes in your 5 MRs are quite small. I suppose the use of jQuery is quite extensive though. How much code to you expect to delete and add to completely remove the jQuery dependency from Postorius? From HyperKitty?
jQuery is a well-known idiom, and provides a lot of features. Which brings up two questions: 1. Would jQuery-based code be significantly easier to maintain, eg, by new developers who don't necessarily know Mailman but do know both js and jQuery? 2. Is there jQuery functionality that we might want to use that would be more complex than the code in the merge_requests you have already?
> I think as next somebody should review the above changes, e.g. try > to deploy them locally and state, that the modified code is > executed, while the behaviour (program logic) does not change.
I'm really not qualified to do this review (especially the issue of whether there might be behavior changes). I'm not sure if Mark or Abhilash is much better able to do so, although I know Abhilash has worked on the Django apps quite a bit and probably on the js parts.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hi Дилян (it's been 30 years since I briefly studied Cyrillic, forgive me for copy/pasting ;-)
Your logic sounds good to me, and I gather the use cases in HyperKitty are different from those in Postorius. So I encourage you to continue work on Postorius and its dependencies (I think that's just django-mailman3), but be careful about proceeding on HyperKitty.
As someone whose "roadwarrior" notebook is a 2016 Mac and primary work tool is XEmacs which hasn't done anything really new since 2010, I do want to be sensitive to people still using old browsers -- if there are any, I bet you'll find them among Mailman admins! I would appreciate it if you keep notes about where there are changes that do NOT have no-javascript alternatives. Abhilash has been doing some work about making the Django apps more no-javascript friendly, so I don't think worries about extreme backward compatibility should stop this kind of modernization.
About the "size of change" estimate, when you do have a handle on that please post here briefly about that and any other interesting aspects of the work.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hello Stephen,
I do want to be sensitive to people still using old browsers
Which browsers are supposed to be supported by django-mailman3, Postorius and Hyperkitty?
So I encourage you to continue work on Postorius and its dependencies About the "size of change" estimate, when you do have a handle on that …
If the currently proposed changes do not progress, it makes no sense to look how to further decrease the dependency on jQuery.
Greetings // Дилян
-----Original Message----- From: Stephen J. Turnbull <steve@turnbull.jp> To: Дилян Палаузов <dpa-mailman@aegee.org> Cc: mailman-developers@python.org Subject: [Mailman-Developers] Re: Review “Less jQuery” changes Date: 25/02/26 08:23:16
Hi Дилян (it's been 30 years since I briefly studied Cyrillic, forgive me for copy/pasting ;-)
Your logic sounds good to me, and I gather the use cases in HyperKitty are different from those in Postorius. So I encourage you to continue work on Postorius and its dependencies (I think that's just django-mailman3), but be careful about proceeding on HyperKitty.
As someone whose "roadwarrior" notebook is a 2016 Mac and primary work tool is XEmacs which hasn't done anything really new since 2010, I do want to be sensitive to people still using old browsers -- if there are any, I bet you'll find them among Mailman admins! I would appreciate it if you keep notes about where there are changes that do NOT have no-javascript alternatives. Abhilash has been doing some work about making the Django apps more no-javascript friendly, so I don't think worries about extreme backward compatibility should stop this kind of modernization.
About the "size of change" estimate, when you do have a handle on that please post here briefly about that and any other interesting aspects of the work.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Дилян Палаузов writes:
I do want to be sensitive to people still using old browsers
Which browsers are supposed to be supported by django-mailman3, Postorius and Hyperkitty?
All of them. We should support netcat as a browser if we can, as far as I'm concerned. I'm not going to veto any changes because they don't display nicely in netcat, obviously.
I think it is reasonable to try to support browsers without Javascript or with script interpretation turned off. That can be done with a .noscript class. It's not your problem to do that, but since you will be working on the templates, if you notice that some elements require JS and don't have .noscript alternatives, you should file issues for those.
For other browsers, if we run into a problem, we'll deal with that when it happens. I'm certainly not going to ask someone to install Windows and Edge or Safari to test them, but if a problem is reported we'll want it fixed.
So I encourage you to continue work on Postorius and its dependencies About the "size of change" estimate, when you do have a handle on that …
If the currently proposed changes do not progress, it makes no sense to look how to further decrease the dependency on jQuery.
If by "progress" you mean "review of MRs", of course we'll do that.
But if you mean you expect us to install partial changes if they don't result in behavior changes, I hate to tell you, but that is not how this works. If you are not going to remove all jQuery dependencies for an application (ie, Postorious or HyperKitty and django-mailman3), we're not going to install partial changes because that means that future developers need to know both idioms well enough to realize they're different ways of saying the same thing.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hello Stephen,
We should support netcat as a browser
Can you provide more information for this browser, as I could not find any references for it.
But if you mean you expect us to install partial changes if they don't result in behavior changes, I hate to tell you, but that is not how this works. If you are not going to remove all jQuery dependencies for an application (ie, Postorious or HyperKitty and django-mailman3), we're not going to install partial changes because that means that future developers need to know both idioms well enough to realize they're different ways of saying the same thing.
As long as the currently proposed changes, which reduce dependency on jQuery, are not integrated, I personally see no point to look at further places to reduce the dependency on jQuery. The opposite is not true: if the currently proposed changes are integrated in the master branch, it does not mean that I will propose further changes. This project (mailman-core and web interfaces) has anyway the very unusual practice, for proposed changed as merge request, to wait (years) until somebody (e.g. by accident) fills a separate issue, which describes the problem, even if the problem is described in the merge request. So may be, or maybe not, the reason why the proposed by me merge requests are not considered is, because I have not filled for each of them a gitlab issue.
One of my considerations is that even if a complete jQuery removal is proposed, it does not mean that the proposal will ever be reviewed. Having one big change - or many small changes which together look big - means that the change is hard to review, while smaller changes now and then are easier to review.
Splitting the whole in smaller steps also implies that many people can contribute somehow to the removal of jQuery - now and then - putting limited time.
I do not buy the argument that using no-jQuery-JavaScript and jQuery (at the same time) prevents development, with the argument that there are people who understand jQuery, but cannot work with JavaScript without jQuery. There are anyway hardly changes in the JavaScript files, not counting embedded JS in html and templates:
For postorius git log -p $(find -name '*.js') shows two lines changed in 2025, zero lines changed in 2024. In 2023 there were 5 lines changed and a migration to bootstrap5 performed. In 2022 zero lines were changed.
Bootstrap 5 implies that these browsers are supported - https://getbootstrap.com/docs/5.0/getting-started/browsers-devices/ .
In Hyperkitty git log -p $(find -name '*.js') shows that the most recent change is from November 2023.
Greetings // Дилян
-----Original Message----- From: Stephen J. Turnbull <steve@turnbull.jp> To: Дилян Палаузов <dpa-mailman@aegee.org> Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Re: Review “Less jQuery” changes Date: 27/02/26 17:01:28
Дилян Палаузов writes:
> > I do want to be sensitive to people still using old browsers > > Which browsers are supposed to be supported by django-mailman3, > Postorius and Hyperkitty?
All of them. We should support netcat as a browser if we can, as far as I'm concerned. I'm not going to veto any changes because they don't display nicely in netcat, obviously.
I think it is reasonable to try to support browsers without Javascript or with script interpretation turned off. That can be done with a .noscript class. It's not your problem to do that, but since you will be working on the templates, if you notice that some elements require JS and don't have .noscript alternatives, you should file issues for those.
For other browsers, if we run into a problem, we'll deal with that when it happens. I'm certainly not going to ask someone to install Windows and Edge or Safari to test them, but if a problem is reported we'll want it fixed.
> > So I encourage you to continue work on Postorius and its > > dependencies About the "size of change" estimate, when you do > > have a handle on that … > > If the currently proposed changes do not progress, it makes no > sense to look how to further decrease the dependency on jQuery.
If by "progress" you mean "review of MRs", of course we'll do that.
But if you mean you expect us to install partial changes if they don't result in behavior changes, I hate to tell you, but that is not how this works. If you are not going to remove all jQuery dependencies for an application (ie, Postorious or HyperKitty and django-mailman3), we're not going to install partial changes because that means that future developers need to know both idioms well enough to realize they're different ways of saying the same thing.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Дилян Палаузов writes:
We should support netcat as a browser
Can you provide more information for this browser, as I could not find any references for it.
"man 1 nc". It's literally cat(1) for network connections. I'm old, my jokes smell of dust and mold.
As long as the currently proposed changes, which reduce dependency on jQuery, are not integrated, I personally see no point to look at further places to reduce the dependency on jQuery.
jQuery is still a dependency for all three modules (Postorius, HyperKitty, and django_mailman3), is it not? The dependency reduction that interests me is when users see pages load more quickly.
Integration is not going to happen for your convenience, because it imposes burdens on other developers. If you or others continue to substitute plain JS for jQuery code, we will be happy to occasionally request testing from beta testers and do our own at significant points (eg, when you remove "import jquery" from one or more files, definitely when Postorius or HyperKitty becomes jQuery-free).
The opposite is not true: if the currently proposed changes are integrated in the master branch, it does not mean that I will propose further changes.
Yes, that's a problem. You've already made it clear that we can't be sure you will complete jQuery removal, so we might get left with a bunch of legacy code we don't want.
This project (mailman-core and web interfaces) has anyway the very unusual practice, for proposed changed as merge request, to wait (years) until somebody (e.g. by accident) fills a separate issue, which describes the problem, even if the problem is described in the merge request.
That is not the practice. It is true that we frequently do request an issue *as documentation* that will show up in searches in the issue database. Speaking of trivial effort: you copy the title of the merge request and description of the merge request and add a link to the MR.
So may be, or maybe not, the reason why the proposed by me merge requests are not considered is, because I have not filled for each of them a gitlab issue.
The reason why merge requests sit there for long periods is because we have very few active committers, and fewer non-committer reviewers. We spend *most* of our time on issues, because they are frequently filed by users who cannot do the work needed. MRs are often filed by people scratching itches that we don't feel at all, or are low quality hacks, so visting the MR page is necessarily lower priority unless our attention is drawn to it by an issue or mailing list post.
I've recently offered to review one MR for two careful reviews of third party MRs. That applies to you, too. Note that by "I will review" I mean to continue the conversation until I make a decision or the contributor abandons it. If I decide to reject, the contributor is welcome to appeal to Mark or Abhilash. Quite often I will recommend that, because my objection is a matter of style or personal taste, and I'm happy to leave final decision to another committer.
One of my considerations is that even if a complete jQuery removal is proposed, it does not mean that the proposal will ever be reviewed. Having one big change - or many small changes which together look big - means that the change is hard to review, while smaller changes now and then are easier to review.
Smaller changes now and then are impossible to review, if you would rather that none of the changes be made unless all of them are.
And the principle fails in general. Backing out a long series of small changes when you realize that the main project is the wrong thing to do can be very painful. In my experience, over 25 years as a reviewer now, reviewing small changes may be necessary in many cases but that does not make reviewing much easier, because you still have to review the final product.
Splitting the whole in smaller steps also implies that many people can contribute somehow to the removal of jQuery - now and then - putting limited time.
Nonsense. This is one role for filing an issue -- it's a place to coordinate. I guess you can do that on a merge request, too. But I (personally, this is not project policy) actually like the division of responsibility where "I'm working on foo.py, expect to request review today + 1 week" is in the issue, while "I'm seeing divergent behavior in bar.py after applying the MR, I think your boilerplate for replacing jquery.baz needs '...'" goes in the MRs. Also, in a case like this where the work is very much split up by file, it's likely that people will just file their own MRs, and now you need a place to coordinate those -- an issue is better for that.
My preferences aside, you're doing the work, so you get to choose how to coordinate any joint work (until you designate someone else or abandon the project). You just don't get to coordinate it on the master branch.
I do not buy the argument that using no-jQuery-JavaScript and jQuery (at the same time) prevents development,
That's not the argument. The argument is that it's an unnecessary cognitive burden which is imposed on every developer who reads those files. You say "make it convenient for me or I won't do the work". I say "make it inconvenient for other developers and they won't do their work." I'm going to back the other developers every time.
You can get the convenience of choosing when your contributions get committed, you know. Do enough work and support other developers well enough to earn a commit bit.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hello Steve,
in the repositories django-mailman3, hyperkitty and postorious all contributions from you I see are:
- https://gitlab.com/mailman/postorius/-/commit/1b532326518584b050d63070c7ec96...
- https://gitlab.com/mailman/postorius/-/commit/bae5d1fb752ddb2a30e14df61082f3...
- https://gitlab.com/mailman/postorius/-/commit/43b47d85f188b6c4db40b7883239ff...
from 2013 and 2018. They do not touch any JavaScript or jQuery code.
As to avoid disagreements on how new code, executed in the browser, should be written, at this moment it would be good to have an assessment on discontinuing jQuery from somebody, who has worked both with jQuery or JavaScript (in Mailman3).
Looking at how much the JavaScript code has changed recently with git log -p $(find -name '*.js') :
In django-mailman this year there is one line changed (by me), and the previous change is from 2016. In hyperkitty in 2026, 2025, 2024 there were no changes. In 2023 and 2022, apart from doing library upgrades, approximately 10 lines were modified each year. In postoruis in 2025 2 lines were modified, in 2024 there were no changes. In 2023, apart from doing library upgrades, 8 lines were modified. The previous change is from 2017 - 1 line modified.
The above numbers do not include embedded JavaScript in html/templates with the script-tag. Yet it gives an idea how much JavaScript development happens in Mailman 3 and how much developers (persons) will be confused if some part of the code is in jQuery and others does not use jQuery.
The reason why merge requests sit there for long periods is because we have very few active committers
In other words, even if all possible requirements are fulfilled by a merge request - separate ticket describing the problem, which ticket is distinct from the merge request; touching or not touching JavaScript/jQuery - it is still unpredictable, if the merge request will be integrated in reasonable time.
Greetings // Дилян
-----Original Message----- From: Stephen J. Turnbull <steve@turnbull.jp> To: Дилян Палаузов <dpa-mailman@aegee.org> Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] Re: Review “Less jQuery” changes Date: 28/02/26 08:49:31
Дилян Палаузов writes:
> > We should support netcat as a browser > > Can you provide more information for this browser, as I could not > find any references for it.
"man 1 nc". It's literally cat(1) for network connections. I'm old, my jokes smell of dust and mold.
> As long as the currently proposed changes, which reduce dependency > on jQuery, are not integrated, I personally see no point to look at > further places to reduce the dependency on jQuery.
jQuery is still a dependency for all three modules (Postorius, HyperKitty, and django_mailman3), is it not? The dependency reduction that interests me is when users see pages load more quickly.
Integration is not going to happen for your convenience, because it imposes burdens on other developers. If you or others continue to substitute plain JS for jQuery code, we will be happy to occasionally request testing from beta testers and do our own at significant points (eg, when you remove "import jquery" from one or more files, definitely when Postorius or HyperKitty becomes jQuery-free).
> The opposite is not true: if the currently proposed changes are > integrated in the master branch, it does not mean that I will > propose further changes.
Yes, that's a problem. You've already made it clear that we can't be sure you will complete jQuery removal, so we might get left with a bunch of legacy code we don't want.
> This project (mailman-core and web interfaces) has anyway > the very unusual practice, for proposed changed as merge request, > to wait (years) until somebody (e.g. by accident) fills a > separate issue, which describes the problem, even if the problem is > described in the merge request.
That is not the practice. It is true that we frequently do request an issue *as documentation* that will show up in searches in the issue database. Speaking of trivial effort: you copy the title of the merge request and description of the merge request and add a link to the MR.
> So may be, or maybe not, the reason why the proposed by me merge > requests are not considered is, because I have not filled for each > of them a gitlab issue.
The reason why merge requests sit there for long periods is because we have very few active committers, and fewer non-committer reviewers. We spend *most* of our time on issues, because they are frequently filed by users who cannot do the work needed. MRs are often filed by people scratching itches that we don't feel at all, or are low quality hacks, so visting the MR page is necessarily lower priority unless our attention is drawn to it by an issue or mailing list post.
I've recently offered to review one MR for two careful reviews of third party MRs. That applies to you, too. Note that by "I will review" I mean to continue the conversation until I make a decision or the contributor abandons it. If I decide to reject, the contributor is welcome to appeal to Mark or Abhilash. Quite often I will recommend that, because my objection is a matter of style or personal taste, and I'm happy to leave final decision to another committer.
> One of my considerations is that even if a complete jQuery removal > is proposed, it does not mean that the proposal will ever be > reviewed. Having one big change - or many small changes which > together look big - means that the change is hard to review, while > smaller changes now and then are easier to review.
Smaller changes now and then are impossible to review, if you would rather that none of the changes be made unless all of them are.
And the principle fails in general. Backing out a long series of small changes when you realize that the main project is the wrong thing to do can be very painful. In my experience, over 25 years as a reviewer now, reviewing small changes may be necessary in many cases but that does not make reviewing much easier, because you still have to review the final product.
> Splitting the whole in smaller steps also implies that many people > can contribute somehow to the removal of jQuery - now and then - > putting limited time.
Nonsense. This is one role for filing an issue -- it's a place to coordinate. I guess you can do that on a merge request, too. But I (personally, this is not project policy) actually like the division of responsibility where "I'm working on foo.py, expect to request review today + 1 week" is in the issue, while "I'm seeing divergent behavior in bar.py after applying the MR, I think your boilerplate for replacing jquery.baz needs '...'" goes in the MRs. Also, in a case like this where the work is very much split up by file, it's likely that people will just file their own MRs, and now you need a place to coordinate those -- an issue is better for that.
My preferences aside, you're doing the work, so you get to choose how to coordinate any joint work (until you designate someone else or abandon the project). You just don't get to coordinate it on the master branch.
> I do not buy the argument that using no-jQuery-JavaScript and > jQuery (at the same time) prevents development,
That's not the argument. The argument is that it's an unnecessary cognitive burden which is imposed on every developer who reads those files. You say "make it convenient for me or I won't do the work". I say "make it inconvenient for other developers and they won't do their work." I'm going to back the other developers every time.
You can get the convenience of choosing when your contributions get committed, you know. Do enough work and support other developers well enough to earn a commit bit.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Дилян Палаузов writes:
in the repositories django-mailman3, hyperkitty and postorious all contributions from you I see are:
Which is relevant in what way?
As to avoid disagreements on how new code, executed in the browser, should be written, at this moment it would be good to have an assessment on discontinuing jQuery from somebody, who has worked both with jQuery or JavaScript (in Mailman3).
"git blame" will tell you who to ask. Most likely of the active developers would be Abhilash, but as you say very little has been done recently, so I don't know if he has relevant experience. Or Mark.
Looking at how much the JavaScript code has changed recently with git log -p $(find -name '*.js') :
Which is relevant, why?
In other words, even if all possible requirements are fulfilled by a merge request - separate ticket describing the problem, which ticket is distinct from the merge request; touching or not touching JavaScript/jQuery - it is still unpredictable, if the merge request will be integrated in reasonable time.
Yes. What is it about "volunteer" that you don't understand?
Thing is, the committers define "reasonable time", as well as what we want to accept. I don't know any project since everyone converted from CVS which will fast track half-baked changes as you propose. You work on a feature branch until you're done, then merge.
You want that to change, become a committer and do something about it.
IMO, committer candidates are not necessarily terribly productive in code. Rather, they're dedicated to helping others get stuff done. They support users on the lists. They write documentation. They work on other people's issues. They review other people's merge requests. They don't commit their own code unless it meets the standards they demand of others.
I don't speak for the other committers, though. If you can get a few of them to support you, I won't oppose even if you don't seem to satisfy my criteria.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (2)
-
Stephen J. Turnbull -
Дилян Палаузов