7 ms·

Yeah. Open source seldom realizes it needs the same infrastructure as a commercial product: separate project management issue queue and support issue queue. Wh

by lotyrin 11y ago

Yeah. Open source seldom realizes it needs the same infrastructure as a commercial product: separate project management issue queue and support issue queue. What are we doing next, what version did we fix Y in, what VCS branch are we working on Z in, who is working on X, etc. are separate from Who reported problem, what version of the product do they report having used, what did they expect and what did they get, is that part of the design of the product, did they ever get back to us, etc. The other problem is ill-defined roles. If everyone's a developer is a support volunteer, is a user, then you can have people be pretty shitty and reflect on the project in a way that they shouldn't be allowed to. Random users should be able to file support tickets, but only to view project management tickets. Only designated volunteers should be able to respond to existing support tickets and create project management tickets from them, these people speak as the public face of your project, that's really really important to have a handle on. Support tickets probably shouldn't be public, for that matter. Now of course this is all unpaid, volunteer -- I'm not saying any of these queues should have a defined SLA or anything. By all means keep project a bazaar -- let support queue handle outside feature requests and feedback and everything -- continue to have a public repos, roadmap and changelog, etc.

cyphar 11y ago
If I used your software, I would totally fork your project and have a less totalitarian view of the project's leadership. You're free to think you "own" your community, but as Oracle and many other examples have told us, that's not the case and the community will make sure you learn your lesson.
- lotyrin 11y ago
  I'm not advocating for anything other than community ownership of projects, only a few formalities. Thinking that everything has to be absolute anarchy in order to be "free" (even that open source's goal has to be to maximise "freedom" over any other kinds of social utility) is a kind of absolutism/idealism that I wish open source communities could leave in high-school where it belongs.
  - cyphar 11y ago
    The two choices are not "anarchy" and "everything except the code we output should be private".
jrochkind1 11y ago
I know what you mean, but there's another side. For instance just on: > Support tickets probably shouldn't be public, for that matter. Open GitHub issues, combined with Google, have turned out surprisingly useful to me as a user of open source packages. Often an answer to some trouble I've run into is found in an issue -- both 'support' ticket style issues, and development roadmap style issues, and the line sometimes gets blurred. Also, there's a positive aspect of the blurring of the boundaries in open source -- when a user contributes code, or documentation. But yeah, people running open source projects need to at least think about how they're going to deal with project management as well as support at some point, and just the thinking about it and the iterating to figure out how to do it better is for some a chore they don't want to do. The projects that figure out how to do this well are the ones that are a joy to use or to contribute to though. Oh, and my experience I'm talking from is with open source code packages meant for use by developers. Open source end-user applications (including OSs like Linux) are a different animal, and are _much harder_ to deal with support and project management and the overlap, in my observation. Not sure which you were thinking of, but now I'm thinking maybe end-user apps.
- lotyrin 11y ago
  Agreed, but I think stack-exchange style communities are better at this than a project's issue queue or a support channel. There's also nothing preventing common support issues getting turned into documentation improvements, creating googleable (but more concise) results. I'd rather find a wiki page for "libchitz Error: Insufficient Flurbos in /var/lib/blips" than a forum post/issue with tens of comments and have to scrape through the results. Also, there's plenty of times googling something should get you a documentation page on a subject but instead gets you forums/issues/etc. that aren't helpful.
  - jrochkind1 11y ago
    > There's also nothing preventing common support issues getting turned into documentation improvements, Nothing but someone with the time, willingness, and skill to do it well. Which is not nothing. A lot of the amazingness of GitHub's effect on our work is how it gives us lots of useful stuff that happens as 'byproducts', without someone needing to spend time and energy to do it well.

by lotyrin 11y ago

cyphar 11y ago

If I used your software, I would totally fork your project and have a less totalitarian view of the project's leadership. You're free to think you "own" your community, but as Oracle and many other examples have told us, that's not the case and the community will make sure you learn your lesson.

lotyrin 11y ago
I'm not advocating for anything other than community ownership of projects, only a few formalities. Thinking that everything has to be absolute anarchy in order to be "free" (even that open source's goal has to be to maximise "freedom" over any other kinds of social utility) is a kind of absolutism/idealism that I wish open source communities could leave in high-school where it belongs.
- cyphar 11y ago
  The two choices are not "anarchy" and "everything except the code we output should be private".

jrochkind1 11y ago

I know what you mean, but there's another side. For instance just on: > Support tickets probably shouldn't be public, for that matter. Open GitHub issues, combined with Google, have turned out surprisingly useful to me as a user of open source packages. Often an answer to some trouble I've run into is found in an issue -- both 'support' ticket style issues, and development roadmap style issues, and the line sometimes gets blurred. Also, there's a positive aspect of the blurring of the boundaries in open source -- when a user contributes code, or documentation. But yeah, people running open source projects need to at least think about how they're going to deal with project management as well as support at some point, and just the thinking about it and the iterating to figure out how to do it better is for some a chore they don't want to do. The projects that figure out how to do this well are the ones that are a joy to use or to contribute to though. Oh, and my experience I'm talking from is with open source code packages meant for use by developers. Open source end-user applications (including OSs like Linux) are a different animal, and are _much harder_ to deal with support and project management and the overlap, in my observation. Not sure which you were thinking of, but now I'm thinking maybe end-user apps.

lotyrin 11y ago
Agreed, but I think stack-exchange style communities are better at this than a project's issue queue or a support channel. There's also nothing preventing common support issues getting turned into documentation improvements, creating googleable (but more concise) results. I'd rather find a wiki page for "libchitz Error: Insufficient Flurbos in /var/lib/blips" than a forum post/issue with tens of comments and have to scrape through the results. Also, there's plenty of times googling something should get you a documentation page on a subject but instead gets you forums/issues/etc. that aren't helpful.
- jrochkind1 11y ago
  > There's also nothing preventing common support issues getting turned into documentation improvements, Nothing but someone with the time, willingness, and skill to do it well. Which is not nothing. A lot of the amazingness of GitHub's effect on our work is how it gives us lots of useful stuff that happens as 'byproducts', without someone needing to spend time and energy to do it well.