Tanmay Singhal via Mailman-Developers writes:
> For Dynamic Sublists, would it make sense to start discussing
> possible design approaches on the mailing list now, or is that
> better left for the formal proposal stage?
Please discuss here. There is existing technology, which I will try
to dig up and provide references. (Dynamic Sublists were an important
project management tool for the Systers organization for a long time,
originally based in Mailman 2.) But until I can publish that, what
are your ideas?
Note: You're not the only one interested in this task. While your
specific proposal will be private to you, generic technical
discussions ("how does <this widget> work?", "how does Mailman
implement <this kind of function>?") should be done here.
> For that project, how important is familiarity with the Postorius
> or HyperKitty codebases?
I am not sure. The Systers implementation was developed pre-Web-2.0,
and the idea was to provide sophisticated technology with an
email-based interface. It was as simple as picking the "parent" list
that targeted your general audience, composing a subject to attract
the "sublist" audience, and adding "-new" to the parent's posting
address. That would automatically create a sublist and assign it a
compact extension to create the list-post address, and you're done.
As a user, that is -- obviously there was a lot of work behind the
scenes.
I think in Mailman 2 archives (I believe they used Pipermail, as
bundled with Mailman 2) they just created a sublist addressed by its
posting address, and otherwise it was just a Pipermail archive.
HyperKitty is much more sophisticated, and
IIRC, there was no admin web UI at all. (Systers had an extensive web
UI, they used Mailman's user/address database as the core of their
membership management as I understand it! But the dynamic lists UI
was "-new" and post, basically.)
> From my understanding most of the core logic would live in
> mailman-core, with the others mainly involved for
> configuration/UI. Would you reccomend I get comfortable with their
> codebases and contribute to them to develop understanding?
I would stick to the core and a maximally simple HyperKitty archiving
facility (this might be as simple as querying "is there a HyperKitty
archive?", then configuring it as with any ordinary list).
> And also, now that I have worked on a few smaller fixes, I’d like
> to start contributing in larger ways. Would it be helpful to
> - begin reviewing other PRs,
> - opening issues I notice,
For GSoC purposes, give these priority. Support for other developers
is very important in our community. "10x" coders, not so much.
> or working on some of the “wishlist” issues , or are those
> generally too large for new contributors to pick up?
That's up to you, but from the point of view of getting a GSoC
internship, writing a proposal and demonstrating collaboration skills
(eg, reviewing) are probably more profitable (to you and to the
community).
Steve
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
_______________________________________________
Mailman-Developers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
