3 ms·

It may just be me, but it seems like you're contradicting yourself with: There's very little software that supports both fly-by questions on the web, and prope

by Zev 17y ago

It may just be me, but it seems like you're contradicting yourself with: There's very little software that supports both fly-by questions on the web, and proper discussion via e-mail, so we optimize for ourselves, not users. and Users don't pay the bills, and questions are usually incredibly repetitive and dull, no matter how easy-to-use or well documented the project is. While there's absolutely nothing wrong with coding for yourself, it doesn't usually pay the bills either. And (sadly), its rarer then it should be for someone to be able to print money for themselves by making things for themselves. I reiterate: If different users are asking the same question repeatedly, perhaps its an indicator that there's something wrong with your software, not your users? Oh, and, incase you don't know, not all software needs to expand until they can read mail. Multitasking has (sans the iPhone, if you want), been around for decades. People are more than capable of having one program open at a time. There's nothing wrong with this. Web forums aren't frictionless. In fact, they're totally shit for the purpose of carrying on detailed conversations over the course of days without requiring constant attention from all the participants. There's a reason why most forums will e-mail you when your watched threads are updated. Why not just have the e-mail be the thread? Nowhere did I say that forums are better than email. They're both equally bad. My personal preference for this sort of thing is IRC. Of course, I'm biased, since one of the projects I spend the most time working on is an IRC client. Also, forums are easier for end users to figure out then mailing lists. You could argue thats because mailing list software tends to suck, but, thats ignoring the issue. I'd rather the users that are unwilling to invest in the mailing list self-segregate by posting their one-offs to sites like StackOverflow. Not all open source projects are programming languages or libraries, which is SO's target area currently seems to be.

antonovka 17y ago
While there's absolutely nothing wrong with coding for yourself, it doesn't usually pay the bills either. And (sadly), its rarer then it should be for someone to be able to print money for themselves by making things for themselves. Feel free to treat "pay the bills" metaphorically. That was my intention. I reiterate: If different users are asking the same question repeatedly, perhaps its an indicator that there's something wrong with your software, not your users? Perhaps. But more often than not it's an inherent complexity in the problem space itself. Oh, and, incase you don't know, not all software needs to expand until they can read mail. Multitasking has (sans the iPhone, if you want), been around for decades. People are more than capable of having one program open at a time. There's nothing wrong with this. I don't follow your meaning ... My personal preference for this sort of thing is IRC. IRC is real-time and ephemeral, which makes it considerably more difficult to engage in conversations with contributors in other time zones, and refer back to design discussions that occurred 5-20 years ago. Also, forums are easier for end users to figure out then mailing lists. I thought we already established that project communication channels are primarily optimized for the project contributors who use them daily, not for once-off questions from end users.
- Zev 17y ago
  Perhaps. But more often than not it's an inherent complexity in the problem space itself. That isn't to say there is only ever one way of performing an action or that it is impossible to make it clearer how to perform a task. And if you make it difficult for users to give you their opinion, it will be that much harder to know what needs to be improved. IRC is real-time and ephemeral, which makes it considerably more difficult to engage in conversations with contributors in other time zones, and refer back to design discussions that occurred 5-20 years ago. There's not very many projects that date back 20 years ago that also have the complexity that you're talking about. X11 and the Linux kernel are the only two I can think of off the top of my head. And I would hope that a 5-20 year old project that's continuously under development would have more documentation than posts from a mailing list about its design. I thought we already established that project communication channels are primarily optimized for the project contributors who use them daily, not for once-off questions from end users. I would be interested in seeing how many projects — open source in this case — have > 1 or 2 contributors. I may be off base, but I'd guess that you're optimizing towards large, highly visible projects and not the small, norm of an open source project.
  - pyre 17y ago
    > That isn't to say there is only ever one way of performing an action or that it is impossible to make it clearer how to perform a task. And if you make it difficult for users to give you their opinion, it will be that much harder to know what needs to be improved. Not to berate users, but sometimes when people run into an issue they want a solution yesterday. So they hop on to the mailinglist/irc and demand to have their problem fixed... Only for more informed people to point them at the FAQ which probably results for the first Google search on problem. I'm not saying that the software could't have flaws. I'm saying that if people are armed with the answer to their issue, then they are more equipped to make suggestions at the future direction of the software. When they still don't have an answer they are still in, "FIX THIS NOW!" mode.
- pyre 17y ago
  > IRC is real-time and ephemeral, which makes it considerably more difficult to engage in conversations with contributors in other time zones, and refer back to design discussions that occurred 5-20 years ago. Lots of places log IRC and host the logs. That might not be your cup of tea, but it's far from hard. And I think that the reason that most design discussions (other than one-off decisions) still happen in email is that you can't really 'write up' something in IRC the way that you can compose an email. > I thought we already established that project communication channels are primarily optimized for the project contributors who use them daily, not for once-off questions from end users. Why not create a web forum/usenet/mailinglist gateway? Launchpad is semi-like this. I haven't pushed the bounds of it, but I can sign in through the bug page and post something. I can also subscribe to the bug and get an email for each post, which I can reply to (though it is limited in that there is no threading, but bug tracking is fairly topical) to post back to the bug page.
pyre 17y ago
> I reiterate: If different users are asking the same question repeatedly, perhaps its an indicator that there's something wrong with your software, not your users? Sometimes the issue is that people have different assumptions about how something should work. Sometimes there's not always an intuitive way to make something easy for every person on the planet to immediately grasp. But this is all a little too abstract without solid examples.

by Zev 17y ago

antonovka 17y ago

While there's absolutely nothing wrong with coding for yourself, it doesn't usually pay the bills either. And (sadly), its rarer then it should be for someone to be able to print money for themselves by making things for themselves. Feel free to treat "pay the bills" metaphorically. That was my intention. I reiterate: If different users are asking the same question repeatedly, perhaps its an indicator that there's something wrong with your software, not your users? Perhaps. But more often than not it's an inherent complexity in the problem space itself. Oh, and, incase you don't know, not all software needs to expand until they can read mail. Multitasking has (sans the iPhone, if you want), been around for decades. People are more than capable of having one program open at a time. There's nothing wrong with this. I don't follow your meaning ... My personal preference for this sort of thing is IRC. IRC is real-time and ephemeral, which makes it considerably more difficult to engage in conversations with contributors in other time zones, and refer back to design discussions that occurred 5-20 years ago. Also, forums are easier for end users to figure out then mailing lists. I thought we already established that project communication channels are primarily optimized for the project contributors who use them daily, not for once-off questions from end users.

Zev 17y ago
Perhaps. But more often than not it's an inherent complexity in the problem space itself. That isn't to say there is only ever one way of performing an action or that it is impossible to make it clearer how to perform a task. And if you make it difficult for users to give you their opinion, it will be that much harder to know what needs to be improved. IRC is real-time and ephemeral, which makes it considerably more difficult to engage in conversations with contributors in other time zones, and refer back to design discussions that occurred 5-20 years ago. There's not very many projects that date back 20 years ago that also have the complexity that you're talking about. X11 and the Linux kernel are the only two I can think of off the top of my head. And I would hope that a 5-20 year old project that's continuously under development would have more documentation than posts from a mailing list about its design. I thought we already established that project communication channels are primarily optimized for the project contributors who use them daily, not for once-off questions from end users. I would be interested in seeing how many projects — open source in this case — have > 1 or 2 contributors. I may be off base, but I'd guess that you're optimizing towards large, highly visible projects and not the small, norm of an open source project.
- pyre 17y ago
  > That isn't to say there is only ever one way of performing an action or that it is impossible to make it clearer how to perform a task. And if you make it difficult for users to give you their opinion, it will be that much harder to know what needs to be improved. Not to berate users, but sometimes when people run into an issue they want a solution yesterday. So they hop on to the mailinglist/irc and demand to have their problem fixed... Only for more informed people to point them at the FAQ which probably results for the first Google search on problem. I'm not saying that the software could't have flaws. I'm saying that if people are armed with the answer to their issue, then they are more equipped to make suggestions at the future direction of the software. When they still don't have an answer they are still in, "FIX THIS NOW!" mode.
pyre 17y ago
> IRC is real-time and ephemeral, which makes it considerably more difficult to engage in conversations with contributors in other time zones, and refer back to design discussions that occurred 5-20 years ago. Lots of places log IRC and host the logs. That might not be your cup of tea, but it's far from hard. And I think that the reason that most design discussions (other than one-off decisions) still happen in email is that you can't really 'write up' something in IRC the way that you can compose an email. > I thought we already established that project communication channels are primarily optimized for the project contributors who use them daily, not for once-off questions from end users. Why not create a web forum/usenet/mailinglist gateway? Launchpad is semi-like this. I haven't pushed the bounds of it, but I can sign in through the bug page and post something. I can also subscribe to the bug and get an email for each post, which I can reply to (though it is limited in that there is no threading, but bug tracking is fairly topical) to post back to the bug page.

pyre 17y ago

> I reiterate: If different users are asking the same question repeatedly, perhaps its an indicator that there's something wrong with your software, not your users? Sometimes the issue is that people have different assumptions about how something should work. Sometimes there's not always an intuitive way to make something easy for every person on the planet to immediately grasp. But this is all a little too abstract without solid examples.