I'm sorry it has taken so long to produce this. It's still not as complete as I would like, but the thread on Python-Ideas makes "doing something now" important. I definitely have a Mailman bias, but I think I've tagged all cases where that affected presentation of this report. Please let me know if you think I've been unfair in any way. Since this is primarily aimed at current SIG members, but will likely be referenced by new ones, I append a brief description of the SIG "charter" and the available channels at the end. Agenda with Item Status ----------------------- 1. Define "overload" by identifying specific issues that make Python channels "tiring" to use, and evaluate the importance of addressing them. So far we have: (a) Proliferation and durability of off-topic threads. (b) A variant of (a) specific to Python-Dev is repeated posting of theoretical objections to patches whose basic rationale was thrashed out in the tracker or on -committers, but those objections have already been satisfactorily rebutted. (c) Nonlinearity of discussion on mailing lists due to concurrent posts which are largely redundant, yet start their own subthreads. (d) Burnout by experts who would like a "you have to be this tall" rule to participate in discussions in their fields. (e) Moderators can't identify bad actors without reading everything or depending on member reports. (f) The pool of moderators is too small. We haven't explicitly evaluated any of the above as valid issues we "must" address. But all have come up frequently or from Important Contributors (including but not limited to the BDFL). I'm probably missing some. Additions or comments on validity welcome. 2. Identify various communication platforms that may improve on the current use of mailing lists as the primary channels for discussions that should be auditable in the future. So far we have: (a) Mailman 2 (mature traditional mailing list). (b) Mailman 3 (immature next-generation mailing list). (c) Discourse (mature(?) best-of-breed web forum) (d) GitHub tracker (mature(?) best-of-breed issue tracker). By "maturity" I means that as far as I know the upstream project believes the platform to be feature-rich, and may not be excited by the idea of supporting our use case. 3. Test the platforms. So far we have: (a) Mailman 2. Obsolete; I believe there is consensus that Mailman 3 is *already* a big improvement over Mailman 2. (b) Mailman 3. Currently the most active channel for Overload-SIG. I believe there is no consensus: Mailing list advocates are happy with it, but at the present it doesn't help enough for those with (good) consumer-grade MUAs, and it can't solve the nonlinearity problem to the extent that discussants use mail. (c) Discourse. Currently inactive. Consensus seems to be that it has many nice features, but overall the level of enthusiasm was not so high. (Sorry for the vagueness, please comment!) (d) GitHub tracker. Unimplemented. 4. Identify features that help address issues defined in 1. (a) Notifications of new threads. (b) Priorization of "interesting" threads by personal criteria. (c) Manual thread muting. (d) Synchronous posting (you can't post unless all posts to date have been "seen" by your client). (e) Thread editing (moving posts to a more appropriate thread, for example). (f) "Voting" to identify bad actors, thus empowering moderators. (g) "Voting" to identify good actors, to automatically identify and/or promote potential moderators from the population of frequent posters. Again, I'm sure I missed a lot. 5. Generate a "feature" matrix from item 4 to provide as much "objective" comparison as we can get. Not started. 6. Discuss "posting topicality" criteria to complement vague judgments of topicality. Chairman's prerogative. AFAIK nobody else really wants to talk about this -- but I consider it essential for real progress. Also note that for the "voting" features (4f, 4g) to work well, we'll need to establish conventions for interpreting "votes", and therefore, rules for when and how members "vote". What We Have Learned So Far --------------------------- Specifics are described as "item status" above. This section is my general, and quite personal, impressions of the tenor of discussion so far. I'm sure nobody is surprised, but it was a good idea to set up best-of-breed implementations of each platform. It has the advantage of allowing "head to head" comparison of modes in one (but only one) realistic setting, that of discussion in this group. I personally was surprised that so many issues came up even without really experiencing any of the issues that lead to formation of this SIG. It also encourages thinking about things like "Mailman with Feature X that Discourse has" (nb, preferring Mailman is my bias, YMMV). I think this is likely because I perceive no consensus of enthusiasm for any of the platforms so far tested (and my bet is that GitHub will be similar: there will be nice features, but no consensus that it dominates the alternatives). I predict this is going to mean that the responsiveness of the projects providing various communivation platforms to our needs, or our willingness (and ability) to develop an appropriate fork, is important. Compare experience with Roundup. About Overload-SIG ------------------ This SIG was established to deal with the problems that occur in mailing lists as the number of participants and posting rates increase. Examples include nonlinearity of threads such as when several posters post highly redundant responses concurrently, and a greater tendency for off-topic threads to persist. These issues have become pressing on python-dev and python-ideas at least. The SIG has several experimental channels using different discussion modes, and is prepared to instantiate more. Currently available: https://discuss.python.org/c/overload-sig This is a Discourse forum, hosted by python.org. Register as usual for Discourse. Currently inactive, mostly we've moved to Mailman 3 *for now*. https://mail.python.org/pipermail/overload-sig/ This is an archived Mailman 2 list, obsoleted by the Mailman 3 list below. Discussion has moved to Mailman 3 permanently. https://mail.python.org/mm3/mailman3/lists/overload-sig@python.org/ This is a Mailman 3 list. We currently use Mozilla Persona for registration and authentication. You can use a couple of social auth systems for authentication, or register your email with Persona in the usual "get a token URI in the mail" fashion. (The Login button leads to a registration link.)
I'm sorry it has taken so long to produce this. It's still not as complete as I would like, but the thread on Python-Ideas makes "doing something now" important. I definitely have a Mailman bias, but I think I've tagged all cases where that affected presentation of this report. Please let me know if you think I've been unfair in any way.
Since this is primarily aimed at current SIG members, but will likely be referenced by new ones, I append a brief description of the SIG "charter" and the available channels at the end.
Agenda with Item Status -----------------------
1. Define "overload" by identifying specific issues that make Python channels "tiring" to use, and evaluate the importance of addressing them. So far we have:
(a) Proliferation and durability of off-topic threads.
(b) A variant of (a) specific to Python-Dev is repeated posting of theoretical objections to patches whose basic rationale was thrashed out in the tracker or on -committers, but those objections have already been satisfactorily rebutted.
(c) Nonlinearity of discussion on mailing lists due to concurrent posts which are largely redundant, yet start their own subthreads.
(d) Burnout by experts who would like a "you have to be this tall" rule to participate in discussions in their fields.
Or to put another way, someone of authority/knowledge has answered the question/point and that means stopping the discussion.
(e) Moderators can't identify bad actors without reading everything or depending on member reports.
(f) The pool of moderators is too small.
We haven't explicitly evaluated any of the above as valid issues we "must" address. But all have come up frequently or from Important Contributors (including but not limited to the BDFL). I'm probably missing some. Additions or comments on validity welcome.
2. Identify various communication platforms that may improve on the current use of mailing lists as the primary channels for discussions that should be auditable in the future. So far we have:
(a) Mailman 2 (mature traditional mailing list).
(b) Mailman 3 (immature next-generation mailing list).
(c) Discourse (mature(?) best-of-breed web forum)
(d) GitHub tracker (mature(?) best-of-breed issue tracker).
By "maturity" I means that as far as I know the upstream project believes the platform to be feature-rich, and may not be excited by the idea of supporting our use case.
3. Test the platforms. So far we have:
(a) Mailman 2. Obsolete; I believe there is consensus that Mailman 3 is *already* a big improvement over Mailman 2.
(b) Mailman 3. Currently the most active channel for Overload-SIG. I believe there is no consensus: Mailing list advocates are happy with it, but at the present it doesn't help enough for those with (good) consumer-grade MUAs, and it can't solve the nonlinearity problem to the extent that discussants use mail.
(c) Discourse. Currently inactive. Consensus seems to be that it has many nice features, but overall the level of enthusiasm was not so high. (Sorry for the vagueness, please comment!)
I liked it and only stopped using it because I moved over to MM3 as the next experimental instance to try out (plus everyone else has seems to have moved over here).
(d) GitHub tracker. Unimplemented.
4. Identify features that help address issues defined in 1.
(a) Notifications of new threads.
(b) Priorization of "interesting" threads by personal criteria.
(c) Manual thread muting.
I think a+c == b (or at least it does for me).
(d) Synchronous posting (you can't post unless all posts to date have been "seen" by your client).
(e) Thread editing (moving posts to a more appropriate thread, for example).
AKA, forking a thread when it veers off-topic.
(f) "Voting" to identify bad actors, thus empowering moderators.
(g) "Voting" to identify good actors, to automatically identify and/or promote potential moderators from the population of frequent posters.
Again, I'm sure I missed a lot.
5. Generate a "feature" matrix from item 4 to provide as much "objective" comparison as we can get.
Not started.
6. Discuss "posting topicality" criteria to complement vague judgments of topicality.
Chairman's prerogative. AFAIK nobody else really wants to talk about this -- but I consider it essential for real progress. Also note that for the "voting" features (4f, 4g) to work well, we'll need to establish conventions for interpreting "votes", and therefore, rules for when and how members "vote".
This should also go along with whether forcing a thread fork or closing the thread is possible (i.e. there's both the cultural issue to be dealt with but also whether there is any tooling to help with it as well). -Brett
What We Have Learned So Far ---------------------------
Specifics are described as "item status" above. This section is my general, and quite personal, impressions of the tenor of discussion so far.
I'm sure nobody is surprised, but it was a good idea to set up best-of-breed implementations of each platform. It has the advantage of allowing "head to head" comparison of modes in one (but only one) realistic setting, that of discussion in this group. I personally was surprised that so many issues came up even without really experiencing any of the issues that lead to formation of this SIG.
It also encourages thinking about things like "Mailman with Feature X that Discourse has" (nb, preferring Mailman is my bias, YMMV). I think this is likely because I perceive no consensus of enthusiasm for any of the platforms so far tested (and my bet is that GitHub will be similar: there will be nice features, but no consensus that it dominates the alternatives).
I predict this is going to mean that the responsiveness of the projects providing various communivation platforms to our needs, or our willingness (and ability) to develop an appropriate fork, is important. Compare experience with Roundup.
About Overload-SIG ------------------
This SIG was established to deal with the problems that occur in mailing lists as the number of participants and posting rates increase. Examples include nonlinearity of threads such as when several posters post highly redundant responses concurrently, and a greater tendency for off-topic threads to persist. These issues have become pressing on python-dev and python-ideas at least.
The SIG has several experimental channels using different discussion modes, and is prepared to instantiate more. Currently available:
https://discuss.python.org/c/overload-sig
This is a Discourse forum, hosted by python.org. Register as usual for Discourse. Currently inactive, mostly we've moved to Mailman 3 *for now*.
https://mail.python.org/pipermail/overload-sig/
This is an archived Mailman 2 list, obsoleted by the Mailman 3 list below. Discussion has moved to Mailman 3 permanently.
https://mail.python.org/mm3/mailman3/lists/overload-sig@python.org/
This is a Mailman 3 list. We currently use Mozilla Persona for registration and authentication. You can use a couple of social auth systems for authentication, or register your email with Persona in the usual "get a token URI in the mail" fashion. (The Login button leads to a registration link.)
On Aug 15, 2016, at 12:38 PM, Brett Cannon <brett@python.org> wrote:
3. Test the platforms. So far we have:
(a) Mailman 2. Obsolete; I believe there is consensus that Mailman 3 is *already* a big improvement over Mailman 2.
(b) Mailman 3. Currently the most active channel for Overload-SIG. I believe there is no consensus: Mailing list advocates are happy with it, but at the present it doesn't help enough for those with (good) consumer-grade MUAs, and it can't solve the nonlinearity problem to the extent that discussants use mail.
For my own uses, MM3 does not appear to be much different than MM2 in how I use it. The centralized management is nice though, but for actual day to day usage it seems that attempting to really use it from anything but your mail client is less useful than using it from your mail client. The built in MUA/editor in Hyperkitty is so bare bones that it *feels* like you’re not actually supposed to use it for day to day usage. As it stand now, I’ve yet to actually completely send a message through it because it’s so basic that anything but a simple reply with no quoting it ends up getting awkward quickly. The overview page for a seems to have an OKish format for listing threads but if you go into the date based views for listing threads there’s pretty hard to read format with a lot of wasted space. It ends up being more frustrating to try and use this to read threads than it is to just use basically any MUA that handles grouping email by “topics” instead of just a big list of all emails. As someone who desperately wants to have a web based interaction with the mailing lists to be my primary interface, with optional email notifications/interaction for “important” things (someone wanting to call attention to a thread to me directly, or for threads that I think are important) I don’t really see the current state of HyperKitty being something that I could use for that.
(c) Discourse. Currently inactive. Consensus seems to be that it has many nice features, but overall the level of enthusiasm was not so high. (Sorry for the vagueness, please comment!)
I liked it and only stopped using it because I moved over to MM3 as the next experimental instance to try out (plus everyone else has seems to have moved over here).
I feel the same FWIW. Regardless of what happens here I may end up trying to move distutils-sig (or the packaging related discussion, even if it’s not still called “distutils-sig”) onto a Discourse instance and combining the PyPA dev channels with it. That can either take the form of piggybacking off of whatever python-dev does for a Discourse instance if we choose that, or standing up a dedicated instance.
(d) GitHub tracker. Unimplemented.
4. Identify features that help address issues defined in 1.
(a) Notifications of new threads.
(b) Priorization of "interesting" threads by personal criteria.
(c) Manual thread muting.
I think a+c == b (or at least it does for me).
It’s kind of like (c), but I think that can be generalized out to per-thread subscription settings. Some threads I want to get email on, some threads I want to only see online, some threads I never want to see. — Donald Stufft
On Aug 15, 2016, at 12:38 PM, Brett Cannon <brett@python.org> wrote:
3. Test the platforms. So far we have:
(a) Mailman 2. Obsolete; I believe there is consensus that Mailman 3 is *already* a big improvement over Mailman 2.
(b) Mailman 3. Currently the most active channel for Overload-SIG. I believe there is no consensus: Mailing list advocates are happy with it, but at the present it doesn't help enough for those with (good) consumer-grade MUAs, and it can't solve the nonlinearity problem to the extent that discussants use mail.
For my own uses, MM3 does not appear to be much different than MM2 in how I use it. The centralized management is nice though, but for actual day to day usage it seems that attempting to really use it from anything but your mail client is less useful than using it from your mail client. The built in MUA/editor in Hyperkitty is so bare bones that it *feels* like you’re not actually supposed to use it for day to day usage. As it stand now, I’ve yet to actually completely send a message through it because it’s so basic that anything but a simple reply with no quoting it ends up getting awkward quickly. The overview page for a seems to have an OKish format for listing threads but if you go into the date based views for listing threads there’s pretty hard to read format with a lot of wasted space. It ends up being more frustrating to try and use this to read threads than it is to just use basically any MUA that handles grouping email by “topics” instead of just a big list of all emails. As someone who desperately wants to have a web based interaction with the mailing lists to be my primary interface, with optional email notifications/interaction for “important” things (someone wanting to call attention to a thread to me directly, or for threads that I think are important) I don’t really see the current state of HyperKitty being something that I could use for that.
(c) Discourse. Currently inactive. Consensus seems to be that it has many nice features, but overall the level of enthusiasm was not so high. (Sorry for the vagueness, please comment!)
I liked it and only stopped using it because I moved over to MM3 as the next experimental instance to try out (plus everyone else has seems to have moved over here).
I feel the same FWIW. Regardless of what happens here I may end up trying to move distutils-sig (or the packaging related discussion, even if it’s not still called “distutils-sig”) onto a Discourse instance and combining the PyPA dev channels with it. That can either take the form of piggybacking off of whatever python-dev does for a Discourse instance if we choose that, or standing up a dedicated instance.
(d) GitHub tracker. Unimplemented.
4. Identify features that help address issues defined in 1.
(a) Notifications of new threads.
(b) Priorization of "interesting" threads by personal criteria.
(c) Manual thread muting.
I think a+c == b (or at least it does for me).
It’s kind of like (c), but I think that can be generalized out to per-thread subscription settings. Some threads I want to get email on, some threads I want to only see online, some threads I never want to see. — Donald Stufft
On 8/15/16, 10:42 AM, "Donald Stufft" <donald@stufft.io> wrote: [snip]
(c) Discourse. Currently inactive. Consensus seems to be that it has many nice features, but overall the level of enthusiasm was not so high. (Sorry for the vagueness, please comment!)
I liked it and only stopped using it because I moved over to MM3 as the next experimental instance to try out (plus everyone else has seems to have moved over here).
I feel the same FWIW. Regardless of what happens here I may end up trying to move distutils-sig (or the packaging related discussion, even if it’s not still called “distutils-sig”) onto a Discourse instance and combining the PyPA dev channels with it. That can either take the form of piggybacking off of whatever python-dev does for a Discourse instance if we choose that, or standing up a dedicated instance.
Just wanted to chime in and say that I also liked Discourse, and think that some non-MUA / email option should at least be tried out with a broader group. GitHub issues is also certainly worth a shot, but it's so simple that it may be difficult for a project the size of Python to effectively manage releases and such with it. It probably needs a closer look first. The one thing I would suggest about Discourse is that we make the notifications more verbose by default. Better to get an email notification and then say 'how do I turn this off' than to not get one and not realize you have a reply because you happened to leave the forums open in a tab somewhere, like I did. ;-) Regards, Kevin
On Aug 15, 2016, at 2:11 PM, Kevin Ollivier <kevin-lists@theolliviers.com> wrote:
The one thing I would suggest about Discourse is that we make the notifications more verbose by default. Better to get an email notification and then say 'how do I turn this off' than to not get one and not realize you have a reply because you happened to leave the forums open in a tab somewhere, like I did. ;-)
This is certainly doable, if we go with Discourse the defaults for new users (e.g. not retroactive to existing users) are fully adjustable. — Donald Stufft
Trimming the CC list which is getting excessive. Donald Stufft writes:
On Aug 15, 2016, at 2:11 PM, Kevin Ollivier <kevin-lists@theolliviers.com> wrote:
The one thing I would suggest about Discourse is that we make the notifications more verbose by default. Better to get an email notification and then say 'how do I turn this off' than to not get one and not realize you have a reply because you happened to leave the forums open in a tab somewhere, like I did. ;-)
Is getting spammed with email on every event really the best we can do? Is there no better way to notify people who hate email? (RSS feed?)
This is certainly doable, if we go with Discourse the defaults for new users (e.g. not retroactive to existing users) are fully adjustable.
Not a major consideration, but "retroactivity" is one thing that Mailman 3 hopes to get right (current GSoC project). Some default styles (collections of option settings) will be installed as a fallback for users with no explicit setting, some default styles will be copied to users' profiles. The former can be changed globally (including existing users), the latter would apply only to new users.
On Aug 16, 2016, at 9:49 AM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Donald Stufft writes:
On Aug 15, 2016, at 2:11 PM, Kevin Ollivier <kevin-lists@theolliviers.com> wrote:
The one thing I would suggest about Discourse is that we make the notifications more verbose by default. Better to get an email notification and then say 'how do I turn this off' than to not get one and not realize you have a reply because you happened to leave the forums open in a tab somewhere, like I did. ;-)
Is getting spammed with email on every event really the best we can do? Is there no better way to notify people who hate email? (RSS feed?)
I don’t know if there is a per-user RSS feed available (it doesn’t appear so?) but there are RSS (and JSON) feeds available for discourse, like: https://discuss.python.org/latest.rss https://discuss.python.org/posts.rss https://discuss.python.org/c/overload-sig.rss https://discuss.python.org/t/evaluation-process-and-other-alternatives/30.rs... I suspect the lack of a per user one is because nobody has gone out of their way to implement it for discourse yet because it would require more than “anonymous” permissions. — Donald Stufft
On Aug 15, 2016, at 03:17 PM, Stephen J. Turnbull wrote:
(b) Mailman 3 (immature next-generation mailing list).
By "maturity" I means that as far as I know the upstream project believes the platform to be feature-rich, and may not be excited by the idea of supporting our use case.
Just to be clear, I very definitely support such use cases in Mailman 3. Finding resources and volunteers to work on them is another matter. ;)
4. Identify features that help address issues defined in 1.
(c) Manual thread muting.
Given sufficient input from moderators (a scarce resource), I could imagine MM3 supporting thread muting. Of course, given the nature of email, someone who is really intent on spinning off a new thread could remove the relevant headers that attach messages to said thread.
(f) "Voting" to identify bad actors, thus empowering moderators.
(g) "Voting" to identify good actors, to automatically identify and/or promote potential moderators from the population of frequent posters.
In Launchpad's implementation of mailing lists, we do have a reputation system, although it's rarely used and not exposed in the ui. I'd like to see the same basic system in MM3, which wouldn't be so hard, although of course with ui exposure. A reputation can be assigned to any user, and that reputation could be used to perform some automated action, such as discarding, rejecting, or holding their messages. Cheers, -Barry
On Aug 15, 2016, at 04:38 PM, Brett Cannon wrote:
This should also go along with whether forcing a thread fork or closing the thread is possible (i.e. there's both the cultural issue to be dealt with but also whether there is any tooling to help with it as well).
One other thought - we want to replace the MM2 topic feature with something called dlists (dynamic lists). Think of them as nosy lists for mailing lists. It's one of my favorite features of Roundup, and I think it would go a long way toward cutting down on inbox overload. Cheers, -Barry
On Aug 16, 2016, at 7:06 PM, Barry Warsaw <barry@python.org> wrote:
On Aug 15, 2016, at 03:17 PM, Stephen J. Turnbull wrote:
(b) Mailman 3 (immature next-generation mailing list).
By "maturity" I means that as far as I know the upstream project believes the platform to be feature-rich, and may not be excited by the idea of supporting our use case.
Just to be clear, I very definitely support such use cases in Mailman 3. Finding resources and volunteers to work on them is another matter. ;)
This is one of my concerns with MM3 to be honest. I don’t know what Mailman’s contributor base or how many developers hours it has available to it. There is however a distinct difference between having the capability to modify the software to do what we want (e.g. it’s all written in Python and is OSS, so I assume everyone on this list is capable of doing it) and having the resources available and the interest to do it. Assuming we identify deficiencies in Mailman do we have the available resources and are they interested in fixing those things? I suspect the answer is “it depends”, but I think it’s something that is important to think about. — Donald Stufft
On Aug 16, 2016, at 07:13 PM, Donald Stufft wrote:
This is one of my concerns with MM3 to be honest. I don’t know what Mailman’s contributor base or how many developers hours it has available to it. There is however a distinct difference between having the capability to modify the software to do what we want (e.g. it’s all written in Python and is OSS, so I assume everyone on this list is capable of doing it) and having the resources available and the interest to do it. Assuming we identify deficiencies in Mailman do we have the available resources and are they interested in fixing those things? I suspect the answer is “it depends”, but I think it’s something that is important to think about.
It's not an invalid concern, to be completely honest. I feel very confident that we have a flexible, robust, approachable architecture and code base, and we *can* do a lot. It's also often relatively easy to add features, and especially expose functionality via REST. Hyperkitty and Postorius are Django apps, so I think those components are more interesting to people, more interesting to work on, and so have a larger draw to gain more contributors. The core, not as much, but it also doesn't need as much work. Our biggest need IMHO is dedicated UI/UX experts. Cheers, -Barry
Barry Warsaw writes:
On Aug 16, 2016, at 07:13 PM, Donald Stufft wrote:
Assuming we identify deficiencies in Mailman do we have the available resources and are they interested in fixing those things? I suspect the answer is “it depends”, but I think it’s something that is important to think about.
It's not an invalid concern, to be completely honest.
We have been quite successful in the recent past getting GSoC support, so I think that "warm bodies" won't be a problem, and the Django and webapp (eg GitHub) integration side of things gets a lot of proposals, though to be frank they have tended not to be very strong. I think if we had more specific project descriptions (the GitHub integration blurb was literally "better GitHub integration" :-P) we'd get better proposals.
Our biggest need IMHO is dedicated UI/UX experts.
Yes (isn't it every app's??), although users who bang hard on the UI combined with a flexible backend and developers who aren't afraid of refactoring the UI can go a long way. Of course all that's blue sky at present.
FWIW I created python/overload-sig and added you all. Here's the tracker: https://github.com/python/overload-sig/issues -- please give it a try! (Oh, and start watching the repo please.) On Wed, Aug 17, 2016 at 2:29 AM, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Barry Warsaw writes:
On Aug 16, 2016, at 07:13 PM, Donald Stufft wrote:
Assuming we identify deficiencies in Mailman do we have the available resources and are they interested in fixing those things? I suspect the answer is “it depends”, but I think it’s something that is important to think about.
It's not an invalid concern, to be completely honest.
We have been quite successful in the recent past getting GSoC support, so I think that "warm bodies" won't be a problem, and the Django and webapp (eg GitHub) integration side of things gets a lot of proposals, though to be frank they have tended not to be very strong. I think if we had more specific project descriptions (the GitHub integration blurb was literally "better GitHub integration" :-P) we'd get better proposals.
Our biggest need IMHO is dedicated UI/UX experts.
Yes (isn't it every app's??), although users who bang hard on the UI combined with a flexible backend and developers who aren't afraid of refactoring the UI can go a long way.
Of course all that's blue sky at present. _______________________________________________ Overload-sig mailing list overload-sig@python.org Options: https://mail.python.org/mm3/mailman3/accounts/list- options/overload-sig.python.org/ Archives: https://mail.python.org/mm3/archives/list/overload-sig@ python.org/
-- --Guido van Rossum (python.org/~guido)
participants (6)
-
Barry Warsaw -
Brett Cannon -
Donald Stufft -
Guido van Rossum -
Kevin Ollivier -
Stephen J. Turnbull