Block posting to infra@d.o except via the issue queue?

+1 for this. I've replied to issue queue posts via e-mail instead of from here, which is just silly. Also I've not seen any discussions on the list over the past few months that couldn't have been done in public.

Not sure I like the idea. It is sometimes more convenient to mail something, for example when you are offline.

I'd much prefer everything was in issues -

* The current text on joining the infrastructure list suggests it's a closed list, but there's nothing in there that couldn't be said in issues here.
* When you look at the infrastructure queue, it often looks dead - even if there's a 20 post e-mail discussion about search solutions which many people could benefit from and contribute to.
* http://drupal.org/project/issues/statistics/infrastructure
* Every issue queue on Drupal.org has dozens of active issues - that doesn't mean we should start talking about core issues via e-mail again (and when people do that on the development list, they often bring up issues that were fixed months ago because they couldn't be bothered to search the issue queue - that's what happens when you fork discussions).
* If certain people need to be brought into discussions, then it's just as easy to send them a link to an issue with a description as it is to cc them in each time and remember to hit reply all.

absolutely +1
I would even prefer to move the devel list into support issues..

mail should be used only as reminder, it is not suitable for discussions.

"mail should be used only as reminder, it is not suitable for discussions." is the most laughable thing I've heard in years. Really. It just boggles my mind. -1 to this whole thing on principle, but I won't complain if it happens (I've already sub'd to the issue queue, and I'd +1 any mailhandler support so that I can continue being the evil Luddite.)

-1

Let's continue this discussion on the mailing list.

Kieran

* My client and my editing interface. A space and an asterisk remains a space
and an asterisk in email (due to the plain text nature of the emails I send)
and I can indent underneath and SOME of the formatting will be retained
(even in variable font rendering). I can't do the same thing here because
the issue queue's input filter doesn't recognize Markdown or anything even
remotely approaching 7-bit standardized formatting.

* I can save a draft in every email program. I can't save a draft comment
here without writing inside a different editor entirely, and then pasting
it in (which is what I'm actually doing).

* There's no threading on Drupal's issue queue. Most modern day email clients
happily handle In-Reply-To mail headers, and will support any layer of
threading. Drupal's threading capability, even if enabled, doesn't come
close to what modern day email clients can do.

* I can maintain my own archive. My comments are /my/ comments, and I want
an archive of them forever, that is retained through my own personal
backups. I can't accomplish the same thing in any website without painful
workflows (the nearest I've made it is with the slogger Mozilla extension,
which I stopped using after a few months).

* I can choose when I'm ready to address the issue by keeping the email in
my inbox and keeping them marked Unread. I can't do that on Drupal.org -
as soon as I hit the page, everything "new" is marked as read, and I'm
forced to remember the last comment I "left off on".

* I can spend hours in an email program drafting my message. Changes to
Drupal's form handling will mean that my comment form expires after a
certain amount of time, potentially losing everything I just wrote.

* Similarly to the above, if the mail server disappears from underneath me,
I won't lose the message - it'll remain in my Drafts folder, waiting to
go out when it can. Some webbased mailers save emails in-progress to
prevent similar catastrophes - Drupal does no such thing.

* Most email programs far more advanced searching capabilities than what
Drupal provides, and at a far faster clip than Drupal's beleaguered
search. These searches tend to be done in a modal dialog so that, if
my search was too fine or too broad, I can tweak it slightly without
having to re-enter all the data, as I have to with Drupal's search.

Now, to specifically address your own #4 which, mind you, I now have to
manually copy and paste snippets from because Drupal doesn't provide
any quote features:

* Similarly to the above, the only way for me to remember a particular
issue is to bookmark it in my browser or assign myself to the issue.
Bookmarking is relatively subpar, and assigning it to myself tends
to indicate that /I'm/ going to "fix it". That's not always the case.

* As for forking the conversation, the infrastructure mailing list has
been around since 2005, whereas the issue queue only appeared in 2007.
If anything forked the discussion, it was the issue queue.

* The inability to see the infrastructure archives is a bum point
and shouldn't have been brought up. It's fixable in 2 minutes.

* The only way for an email thread to fall off the radar is if people
delete the thread from their mailbox. This almost certainly indicates
a lack of disinterest or time. The amount of effort to manage one's
inbox, which most assuredly people spend more time in, is equal, IMO,
to maintaining a project queue. Unlike the issue queue, however, when
I'm not interested in a particular discussion, I can delete it (either
via "delete thread" or manual delete presses, about as mindless as
ignoring a commercial or banner ad). I can not do the same thing
in the issue queue, however: the issues I care little about will
always be there.

Crappy formatting of this comment brought to you by the issue queue.

* Unlike email, you can't take back a message. This may prove embarrassing
for typos or misunderstandings, but it's a great benefit when it comes
to unmodifiable history. Drupal's issue queue allows me to edit my
comment, presuming no one else has responded since I made it. This would
certainly allow me to fix a mispelling, but it tends to create the
"EDIT: " behavior: "here's some new stuff for you to read". Unfortunately,
EDITs like this are too late - people may have already read the comment
(and aren't expecting anything additional) or, in the case of emailed
subscribes, won't ever receive the updated edit.

* I will agree that some of my previous laments are "solved" by merely
subscribing to the issue queue. That's still not entirely ideal, however
- the received email is the /entire/ issue's comments, which is almost
assuredly far more than I actually care to receive - most folks don't
need to relook over comments 1 through 50 in a thread, but we're always
forced to do so when we scroll to the bottom of the issue queue (or watch
a 100k email get downloaded).

* An "action-oriented [task]" is "Do this". A discussion is "should we do
this?". If the issue queue is for actions, this issue, and others like
it, shouldn't be here - they're not actions. The infrastructure queue
is action-oriented; the infrastructure mailing list is discussion
oriented. Anything with a question mark in it is a discussion. "Block
posting except via issue queue" == agreed-upon action. Add a question
mark, and it's not an action (unless you want to get all meta by
suggesting that "having a discussion" is an action, but that's lame).

Why don't I fix them? Maybe because email isn't broken? ;) You're suggesting that I spend buttloads of time to invent something to replace email. That's just not an argument I can even begin to agree with. [EDIT: More to come, but I don't have time right now to respond. /me grins.].

Re: threads. I'm talking about replies to an email - literally, an "In-Reply-To". They're not new topics. I'm talking about hierarchal replies to a single email thread, where I can see that Email #13 is specifically in response to Email #5 (due to In-Reply-To threading and indents in Thunderbird), whereas I don't get the capability here (save comments like "reply to #4", which cause me to scroll upwards furiously because there's no quote, and no context, to any single comment/reply).

The only rationale that I can see for Gerhard wontfixing opening the archives is because there's sekrit shit in the archives that shouldn't be public to Google. Which assumes that future sekrit shit would be necessary, which precludes the use of issue tracker entirely. Where does said sekrit shit now go?

Meant to say: "Unlike email, you CAN take back a message." [EDIT: /me grins. And it is NOT like the Submit button because, here I am, adding stuff that I wouldn't be able to do in an email message.] I could delete my entire #17 if I wanted to, or add in a whole 'nother paragraph, because no one else has replied to it. To people who have already read my #17, they're gonna miss my EDITs (unless they manually reread it, which doesn't tend to happen unless they're specifically going to respond to it). And, the emailed message that the issue queue sends will never resend out the EDITs. It's historial breakage. #17 is no longer #17 - it's #17 1/2.

To respond to my #15 (scroll up, readers, scroll up. Or down if you're reading this in email): I talked to the maintainer of quote.module and spoiler.module long ago, and he had agreed to turn maintainership over to me. But "just" installing the quote.module on the issue queue wouldn't solve my "I have to cut and paste" lament. The problem is that every quote module for forums/whatevers in existence puts a [QUOTE][/QUOTE] around the entire quoted message. This means that, for me to reply to a specific portion (say, paragraph two of five), I have to manually add [/QUOTE][QUOTE] to insert my text in the middle of it. Lots of typing for no apparent reason. I would, instead, (and if I ever get around to it, implement), a [QUOTE][/QUOTE] around every block in a reply, to more adequately replicate email replying behavior (i.e., replying to the middle of something). These extra QUOTEs would go away on render (if nothing was in-between them) so that they'd not be rendered as visually separate blocks (though, discussion-wise, paragraphs DO tend to mean semantically separate arguments).

"Please. How many tasks/features/bugs in the core issue queue require a lot of discussion before you can actually "do" them?" - conflict of interest. You're suggesting, on one hand, that the infrastructure discussion list should be moved to issue queues (with actionable items), but then suggesting that every OTHER issue queue has an /alternate means of discussion/. They don't (assume contrib modules). It's only natural that other issue queues become discussions because /there's nothing else for them to use/. I'll explicitly concede the issue status point (I assume that absence of comeback concedes acceptance of other points).

You demonstrate one of the biggest problems with your "re #15" and "re #16". In an email client, people tend to include part of 15 (or all of 15, assuming it was small) as a precursor to their comments, with clearly prefixed sentences (which email clients understand and can visually theme as you'd like). But, for me to recall what you're talking about, I have to scroll upwards to 15, losing my comment box. Scroll up, read a sentence, scroll down, respond to it. Do it again. Are you suggesting I open a secondary browser window (not tab) and have two monitors, or manually resize each window so that they'll fit cleanly on a single screen?

The problem, as I see it, is that the issue queue encourages responding to multiple comments and people at the same time, and referring to each as "re #15" or having to manually copy, paste, and format my own quotes. That doesn't happen with a mailing list (and, when it does, very rarely). If I click on a particular comment's "reply" button (say, #15), and then respond as I see it on the screen, it loses ALL context when rendered on the issue - since it would become #21, unthreaded beneath #15. Unless I wrote my comment as a term paper ("I believe that Alaska is full of wolves because..."), the comment loses its context. It's confusing.

I agree. [*YOU* figure out which comment's "reply" I wrote this on.]

Once we get past the bicker and discuss phase on this issue we're going to be at the point we want to close it and open a more focused issue or set of issues that don't have a long discussion that only partially applies anymore. That's what I always figured the point of discussion mediums like irc and the mailing list where for. I think this thread has been pretty good at displaying if not enumerating some of the weaknesses of the issue queue as a discussion medium.

PS - Another point that can't be visually shown here is I cut this comment and refreshed the page to see that there had been comments since I started typing.

And another posted while I was adding the PS...

I think this issue is sort of fixed.