Alternative to Mailing Lists #16916
Comments
|
The new repo should be used for discussion / designing features for those language. When a feature is deemed worthy to be presented to the LDM a proposal is made in the main (repo), by a trusted community member(s) only. The LDM can ruminate over the proposal, and any feedback can be pass to respective language design repo. Discussion on the feedback is in the respective language repo, not
Humbly as an example, you only need to look my closed issues and PRs, to see the what should have be mitigated. If a language proposal first appears on |
|
@jasonmalinowski whilst you're in the |
|
Discourse? http://www.discourse.org/ is mailing list, discussion forum, long-form chat room - just a shame they went with Ruby; otherwise would have been 💯 😛 |
|
@benaadams Yup, I just moved my comment to #16905 since not everybody subscribed to this thread. :) |
|
It's the one that Jeff Atwood (codinghorror.com) works on (former .NET developer). I wonder what "mailman" went with. Assembly? |
|
We use Discourse; would recommend; and works with Github logins. Though our user interaction isn't as wild as Rosyln; but has all sorts of features http://www.discourse.org/about/ including operation via email, so people that like mailing lists can pretend its just a mailing list 😉 Can also integrate it with the comment section of the blog posts; have a private section if you need something NDA/MVP's; bring in all the dotnet mailing lists and then all of the discussion is happening in the same place, even if its happening at disparate properties (like blog posts) Think has the the full list of requirements outlined by @HaloFour |
|
@benaadams What's wrong with Ruby? Discourse can always join forces with GitHub and spend a few million on JRuby or Crystal if they don't like wasting megawatt-hours on yarv, like FB did with php. |
|
Not sure they had assembler when mailman was created. I think it's programmed by swapping valves in and out. |
|
@orthoxerox nothing's wrong with Ruby; just would have been icing on the cake if it was C# or VB.NET for discussing the evolution of those languages |
FYI: here is a blog post on that. Since they've hosted mailman's Python, I think that would be no trouble to host discourse's Ruby. |
|
Discourse was my immediate thought when I first read about the move. In response to the LDT's desire for threaded conversation, that's traditionally mutually exclusive against the ability to scroll down and take in an entire conversation, but Discourse is one of the few things that finds the best of both worlds. https://blog.codinghorror.com/web-discussions-flat-by-design/ |
|
I'll repeat what I said before at #16905 because @MadsTorgersen wrote we should write our suggestions here so what I'm proposing is pretty simple: The design team already created two repos for C# and VB.NET so I think that we can just move the design discussions to these repos and do what we always did, only that when a proposal is accepted then someone from the design team would have to tell the person to send a PR. The community can still discuss the proposal at the original issue that was created, the PR can be updated based on the design decisions that are made and that's it. I really don't see a reason to move from GitHub and I think that the same process that applies to the development of the software's codebase can be applied to the development of any other content and managing proposals isn't an exception. The process can be iterated on and improved but anyway, if the suggestion I made isn't acceptable Discourse would be my second choice. |
|
I agree with @eyalsk, it is the most natural move without any dramatic changes to the platform or anything, however, the team specifically raised concerns regarding administration and management; there would be no difference if we just move the discussions over to another repo. I think the requirements should be laid out by the team themselves and then viable options could be discussed. I thought about a community-moderated repo (or even "moderator" users in Discourse) but that doesn't seem to be a straightforward approach as there are a lot other aspects that could come up. Either way, I wonder how existing proposals are going to be migrated to the new repo/platform to be assigned to active, adopted, or rejected lists? They are already labeled as backlog, planning or ready, but the new categories are quite different. |
|
GitHub issues aren't great for design. The only appeal I see is the current community which exists here. Though I don't even find that argument compelling... it's easy to sign up for other services. |
|
Aside: rust is also going to drop issues for language discussions. https://internals.rust-lang.org/t/the-rfc-issue-tracker/4723 |
|
There are two groups of people that we should try to accommodate. The language design team wants/needs a convenient medium to discuss the minutiae of (very) promising proposals. There's going to be lots of back-and-forth comments, questions and agreements between decision makers. This is their actual job, so they should use whatever they want. We, the outsiders, want a convenient medium to mainly watch these discussions from the sidelines, but we also want a place to discuss and classify the backlog of ideas, preferably with someone from the design team pitching in. The problem with the current (lack of) solution is that the mailing list is not a good place for the backlog. The proposals are kept in the repo, but adding something to it (even if there's a separate folder for the untriaged proposals) is a much more daunting task than starting a conversation on the tracker: first you have to subscribe to the list, then pitch your proposal there, then rewrite it as a PR and send a link to the list, then discuss it on the list again. An outsider will not be able to smoothly join the process. |
This doesn't make sense to me, do you mean discussions?
Why do you think it's the only appeal?
You see, unlike you I think that GitHub is a great place for discussions. Signing up to another service is obviously not the problem, the thing is why do we even need to sign up to another service if it works perfectly fine for us here? well, at least for some of us but if it doesn't work for you then I think that it would better to write what exactly doesn't work for you. Now, I don't say that GitHub is perfect and I don't mind sign up to another service but I think that like @alrz said the team should be crystal clear about the intents and requirements and what exactly are the problems for them so we can have a fruitful discussion about it. |
|
@orthoxerox Third group also: which is raising and resolving issues directly related to the the code in this repo. |
|
@benaadams Well, if we leave they will have the tracker all to themselves. I don't think the compiler team will be inconvenienced by that. |
|
In case anyone happens to have not been paying too close attention, https://internals.rust-lang.org/ is a discourse forum largely being used for the same purposes these mailing lists are being intended for. I think that community, while significantly smaller in terms of general users probably has a far higher % of users participating in the online communities (the rust subreddit is about 2/3rds the size of the csharp one and the rust github has maintained similar activity to what roslyn has had this year since 2011). |
@orthoxerox That's exactly how discourse would work, since it does have a mailing list mode, anyone can opt-in to emails, while outsiders could use the web interface. The proposal process remains as-is as mentioned in dotnet/csharplang repo, just change the first step to link to the discourse instance. |
|
@eyalsk The GitHub issue tracker seems built for a relatively small number of issues, since its query capabilities are weak (as discussed already). The C# language has a huge community which will only grow larger if the language continues to prosper. Certainly this will also result in more involvement and more proposals. GH issues are great for short, focused threads (e.g. "this is obviously a bug, go fix it"). They also have good integration with code, pull requests, commits, etc. That's the sweet spot. But none of that really applies to language design; the best proposals always have multiple threads of discussion about different aspects of the proposal and become quite difficult to follow. OTOH, markdown/code snippets are a good aspect. Tags (for categorization) and reactions (for voting/approval) are also nice. I wish those worked on mobile as well as on desktop. |
|
While discourse is the only alternative that is being suggested so far (beside csharplang issues), I'm not convinced yet that it could be the "best" choice, considering how discussions were going on so far on this repo, discourse lacks a feature that might be crucial for managing issues that often have had opened here on GitHub, for example. discourse does not link and back-link threads to each other like GitHub does for issue links. That's actually quite useful for handling duplicates among other things. But that's about it. It's well-equipped in every other aspects. EDIT: I'd be ok with url links though. Just to point out that there is this lack of feature. |
|
@bondsbw Maybe we can take some of these concerns to the GitHub team and maybe they will improve these things, not just for the Roslyn team but for everyone else. I really see no reason to change if anything I see an opportunity to improve GitHub. |
|
@bondsbw I hope it will be soon but really I dislike the other options and GitHub just grew on me. |
|
To @eyalsk's point, they urged us to just give mailing lists a chance. I would have urged them to go halfway initially and just give GitHub a chance for a few month with the isolated repo which is a great idea, while working with GitHub and perhaps Discourse for some more permanent solution. As they said, the picture does change when there's only one repo where everything is just their stuff. Discourse seems to be the closest thing we know of, but it does have some disadvantages. The one that comes to mind is automatic crosslinks with GitHub issues, PRs, and commits. |
|
I will make the comment that in terms of features mailing lists seem to set a really low bar. We can assume that nobody chose mailman because it has an archive view. So we can assume that the most important feature to enough members of the LDM is email integration. Specifically that they can post an email to some address and it creates a new "discussion", can reply to those emails to continue a discussion which supports tracking the Message-ID enabling threaded discussions (at least in the email client) and can receive emails for any new "discussions" or replies to existing "discussions". Maybe they also care about curating users via some kind of sign-up process? So, if the LDM doesn't care at all about a centralized forum/view, I say we look into whichever solution gives us the best integration with mailing lists. We can start by asking the question as to where Github lacks email integration here. I don't think that you can open a new issue via an email. I don't know that it supports tracking the Message-ID header for threading either. Discourse appears to have a "mailing list mode" which is explicitly described as supporting users who prefer to communicate via email without visiting the forum. |
|
I think if you really want to do that, it's more practical to just open PRs for Discourse. |
|
My favorite quote along the lines of some of the above is, "A good solution today is better than a perfect solution tomorrow". Yeah, build is a stretch, certainly not a short-term option, with a high risk/ambition ratio. I wouldn't normally put it out there, but if for no other reason than to be discounted, it needed to be in the analysis. When I thought about it a little, it seemed there would be some benefits for Microsoft in the bigger picture, so I put a little of that in there. The post was really more aimed at that aspect than anything else. It may trigger something at MS that could lead to value for us down the road. Sometimes there are valid cases of solutions looking for a problem. I looked at it from that perspective. |
|
@DavidArno You literally just said:
And now you're stating just a few hours later:
I'm sorry, but i'm no longer interested in engaging with you on this topic. I'm came to these topics to discuss things and to give an open and honest accounting of my thoughts on the matter. I've never held back anything an i think I've been very considerate and respectful of all the opinions shared so far. |
IMO, we're all influencing each other. I don't particularly think that Swift is particularly special. (Though i am happy to see their library approach to string handling, and would love efforts in that area in .Net land in the future).
I follow Rust quite closely. It's a language i'm super excited about (and i've been using a fair bit in my own time). I just don't do it in Outlook (which is a bit annoying). But Rust is its own project, and i think its great they do things their own way! :) |
Actually, it does send a Message-ID unique to the comment that generated the email notification: I don't know that it actually does anything with it. Github doesn't seem to track that a comment is in reply to any other comment. Even if the conversation happened entirely via email replies the Message-ID would probably always contain the unique ID of the comment which triggered the notification. |
Without question, email is no panacea. I don't think it's being argued as such. The question comes down to pros/cons, and which systems people best feel facilitate manageable communications. For example, i find email much easier to deal with because i can easily track what i've actually read/responded to. For example:
|
I'd like some clarification on that. What would be hte problem with that? In the github world, we'd just link to the conversation. In the proposal world, we'd link to the archive. Is that really not ok? -- Edit: Why the frowny face? I'm asking an honest question. Why is a link to one conversation on a github page ok, but a link to another conversation on mailman not? Thanks! |
Note: there seems to be something broken about how github does this. I'm communicating with github on this issue. |
No, it's not. For starters, it's an abysmal user experience. You'd have to find where that proposal first started and track that down in the archive to link directly. And that link only gets you the comments from that calendar month. If you want the entire discussion, you'd need to track down every month in which that discussion progressed and link the first message from each thread. Second, it's plain-text, and the source examples I've included thus far are wrecked. I honestly can't believe you suggested it. |
|
@CyrusNajmabadi It depends on how thorough the list of proposals in the repo will be, including rejected ones. Right now it's a breeze for a newcomer to filter the proposals/issues. Searching for the root message of a conversation is much harder. And if they want to restart a discussion they have to start a new thread. Someone will have to religiously catalogue and triage the proposals in the repo to make them a useful knowledge base |
Look. I get that for some people here this is a black/white issue, and it's completely incomprehensible that some people would have different opinions, or would want more information :) Can we please get past that stage. We are literally here because there is obviously differing views about what a suitable system would be like. So, when i ask a question, openly and honestly, it would be great if we could just all discuss the issue and actually be clear about what we do/don't like about it :) I don't get to go into meetings and say "i honestly can't believe you suggested it" to colleagues. Well... i could do that... but it wouldn't take things very far. Instead, we discuss things. We lay out pros and cons. We evaluate. And we do so understanding that everyone in the room really wants a positive outcome. Just that different people have different ideas about what that outcome is. |
|
Considering proposals don't make it to the repo until someone from the LDM invites them to submit a PR and that PR is merged, I imagine that most of the proposals submitted to the mailing list will go unconsidered. But that just leaves them as old messages buried in the archive with no easy way to find out why they're in the state that they're in short of reading all of the messages, which will be a massively fun endeavor if the discussion happens to span multiple calendar months. I can tell you with a high degree of certainty that I'm not going to be burrowing through that pile to reply to the multitude of "dupes" that are likely to be proposed.
Considering the frequency of messages I posted specifically on the subject of how awful the archive is, you knew my opinion on the suggestion before you made it. Repetition won't make me change my mind. I'm also not seeing a single rebuttal. |
|
I'm going to go out on a limb and assume that you aren't a proponent of mailing lists specifically because of the implementation of the archive at lists.dot.net. It's clear that there are much better archives out there. So let me ask you this point-blank: Does it matter to you what system is used if the email integration behaved similarly to how a mailing list would work? If you could interact with it exclusively via email, and it would support the |
I suppose you vote and voice your concerns, right? Unless you are not part of the team. So it all comes down to whether the community is a part of the process or not. If so, I suppose we have a right to vote, unless we are not, and we don't. |
|
As someone who still hasn't gotten a mailing list confirmation email (I've tried signing up 3 times in the past few days), I can attest that someone visiting the archives because they haven't been confirmed or because they just want to follow without participating will likely look for other things to do. At least consider upgrading to Mailman 3, which has a modernized UI. I can't attest to it being better than GitHub or Discourse, but it is far better than Mailman 2. |
To be honest, the feeling is fairly mutual. You have misquoted me, from a message I accepted was said in ill-temper and that I deleted, Further, despite this thread being about alternatives to mailman, and despite around 5% of respondents to the survey saying they want a mailing list as their first choice and only 10% wanting it as either first or second choice, you keep trying to sell the alleged pros of mailing lists here. If you wish to join in the discussion around alternatives, please do. This is the thread for that. It isn't appropriate for you to keep trying to change the topic back to the rejected idea of mailing lists though. |
|
I think I found a good example of Mailman 3 and its HyperKitty archiver: |
|
Mailman 3 is certainly much better. Judging from the Fedora mailing lists it looks like it addresses a number of my concerns, although certainly not all. Here's a link to one of their archives: Immediately I see a search facility, limited reactions and what seems like a way to post/reply from the portal. I don't see tags/labels or content formatting (of the archives). Also looking at an LWN article regarding Mailman 3.0. Here's a nice little nugget:
One of the comments of that article also mentions DFeed, an NNTP front-end used by the D language forum. That seems quite nice, and fast. Also doesn't seem to have content formatting, though. |
The reasons I support GitHub over other platforms is as follow:
BTW, one of the things that bothers me with this change is today, we can post suggestions that aren't really related to language design like IDE features so is the Roslyn repo still going to be the place for that? @CyrusNajmabadi I think that telling people that you don't want to engage with them on this topic is not the way to go. Some people are more impulsive than others and that's fine, some people do more mistakes and some people are bad at expressing themselves and that's fine too. It's easy to dismiss people when they are frustrated and mad and knowing @DavidArno based on his posts I think that he really wants the best for the language. I agree that we need some stoppers and there is a way to express frustration too but well, we're not perfect, aren't we? :) |
Yes, but you don't need a mailing list for that. Something with email notifications is enough and both GitHub and Discourse (and probably almost any other option) have them. (Using email notifications on the Roslyn repo doesn't make much sense, because it includes too much stuff that's not language design, like bugfix PRs and IDE issues. But that's already solved by the move to separate repos for language design.) I think this leaves mailing list with only one advantage: threads. And I don't see how that could be enough to outweigh all the disadvantages. |
|
All, thank you for engaging so strongly (and mostly constructively 😀) in this issue. I applaud the initiative to create a survey, and I encourage everyone to express their preferences there (once! 😉). I am unfamiliar with Discourse, and I want to look at it more closely to see if it is a feasible alternative for us. When the C# Language Design team gets together later this week, we'll talk this whole issue over based on your feedback and our research. On the whole, I expect that we can reach a decision by the end of this week. Depending on what it is, it may take shorter or longer to implement. Either way, I'll get back to you. Thanks, Mads |
|
Thank you for the consideration. I wish the survey could represent a wider range of potential options but we were kind of rushing here. I have to believe that there is some kind of compromise that would make almost everyone happy. I know that emotions (and tempers) have been running a little high. While I apologize for the incivility expressed by myself and some other members here I hope that everyone at least recognizes that its born out of a real passion that the community has for C# and being a part of its continuing evolution. |
I really hope we won't have to go through all that again but if Discourse or GitHub will get ruled out, hopefully, we will have time to create a new survey with more options. |
|
Currently, I try to always read the Language Design Meeting Notes (which I can find based on the tag in GitHub), to get a general idea what topics are being discussed. Those link to the proposals, and then I can read all the comments on those proposals that I care about, start-to-finish. Then I can subscribe to them to just get emailed when there are new comments. I can also search by keyword for other similar proposals and subscribe to them, too. It'd be great if the new solution were at least as good as GitHub for (1) following the proposals I care about while ignoring those I don't, and (2) getting caught up on everything that's already been said about a proposal when I decide to start following it. With the email solution, I guess it could work if none of the discussion happened before I subscribed to the list, and if I set up 2 folders (one for all the emails on issues I don't care about, and one for all the emails on issues I do care about) and then I keep adding rules to redirect emails to the latter folder whenever I want to start following a new proposal. But that seems like somewhat more work than just clicking "subscribe" on the thread in GitHub, and being able to follow hyperlinks from one proposal to another instead of having to search. |
|
The C# and VB design teams have a recommendation for where and how to conduct language design discussion: #17054. Please comment there by Friday Feb 10! Thanks, Mads |
|
Closed per #17054 |
and others
Given #16905 there is a bit of concern over the migration of language proposal and discussion from GitHub to mailing lists. I don't have the full list of reasons as to why this migration was announced, however it sounds like primary reasons include the difficulty in managing tasks mixed with discussion in GitHub and the lack of threaded discussions. The purpose of this issue is to track the goals and features of the interested parties to determine if there might be better options.
@eyalsk has started a SurveyMonkey poll where you can vote for your primary or secondary preference between Github, Discourse, mailing lists or "other". If you feel that "other" would be a better choice feel free to elaborate on this issue or here. Results can be found here.
Goals
Features
@userin GitHub)Update 1:
Update 2:
The text was updated successfully, but these errors were encountered: