FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
1–10 of 39 posts
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#2>Q: Would you guys consider moving off Google groups to a real mailing list?
>Sure if there was a good reason.
I haven't checked their group specifically, but every other Google Group I've tried to join without using my gmail account simply refused to let me join. People seem to insist that it's possible, but every time I've tried it's put me in an endless "verify your email" loop.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#3> Why is our infrastructure important to you?
Presumably because it affects how difficult it would be to contribute to the project? This sort of "us v them" outlook seems to be at odds with the nature of open source.
I know a few Haskell projects moved from Darcs to Git recently. While it's sad because Darcs is awesome and underused, lowering the barrier to contribute is probably a net good. Questions about infrastructure like this are by no means unreasonable.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#4Sounds like whining when I read it out loud
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#5This "FOQ" does not come off as anything but something written by someone on a very high horse.
For a project owner to need to write a page about these common questions, why would you not instead implement these common requests?
I've often done this in some of my projects, which could be considered a microcosm of this.
I've never heard of this application, but if there is a module system, why not write a few modules for some other people? Unless your api is horrible, it shouldn't be too difficult to implement all of the "Why Didn't You Implement My Favorite Feature?" if you are familiar with the code base.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#6I totally understand where this is coming from. Any software project of non-trivial size has a certain kind of inertia. The code is written a certain way, the infrastructure works a certain way, the processes and culture are a certain way, because they have evolved over time and often at great cost. Changing them is not easy, and not to be undertaken lightly. That doesn't mean e.g. that moving to GitHub is absolutely verboten, but the gain in convenience for (some) users might be offset by a total stoppage of development during the transition. Then there's likely to be a general slowdown for a while as new secondary issues are found and addressed, as current developers make mistakes with the new processes, etc. If the same users who demand that change are also demanding that their favorite features be implemented (by someone else) right away, they're putting the developers in an impossible situation. Nobody appreciates that. There always seem to be some users with an overdeveloped sense of entitlement, and that can utterly ruin a project for everyone including the other users.
That said, I have to take serious issue with one point.
> We write software. We don't make packages. Talk to your package maintainer.
Wrong. I have lots of friends who are active package maintainers. Theirs is often a thankless job, especially now that so many people seem to think the whole idea of packages is outdated now that we have containers instead (BTW they're wrong). Developers don't have to become experts in every packaging system or its rules, but they can't shirk all responsibility for packaging either. They need to work with package maintainers, fixing (and not re-creating) problems that make packaging difficult. Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery, as I see in the first paragraph of the other Taskwarrior article posted today. Packaging is an essential part of the process.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#7This "FOQ" does not come off as anything but something written by someone on a very high horse. For a project owner to need to write a page about these common questions, why would you not instead implement these common requests? I've often done this in some of my projects, which could be considered a microcosm of this. I've never heard of this application, but if there is a module system, why not write a few modules…
> why would you not instead implement these common requests?
Because time is finite. Apparently you're one of the few developers that doesn't have 10x more feature requests than you have resources to work on them. Good for you. However, that's not the norm.
> why not write a few modules for some other people?
See above. It's a mistake to generalize from young and/or small projects to those that have become large and complex over time.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#8Cool, I'll continue not using and not contributing to this project I've never heard of until just now.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#9This "FOQ" does not come off as anything but something written by someone on a very high horse. For a project owner to need to write a page about these common questions, why would you not instead implement these common requests? I've often done this in some of my projects, which could be considered a microcosm of this. I've never heard of this application, but if there is a module system, why not write a few modules…
For a project owner to need to write a page about these common questions, why would you not instead implement these common requests?
The whole document is about answering each of those common questions individually.
Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
#10This "FOQ" does not come off as anything but something written by someone on a very high horse. For a project owner to need to write a page about these common questions, why would you not instead implement these common requests? I've often done this in some of my projects, which could be considered a microcosm of this. I've never heard of this application, but if there is a module system, why not write a few modules…
> why would you not instead implement these common requests? Because time is finite. Apparently you're one of the few developers that doesn't have 10x more feature requests than you have resources to work on them. Good for you. However, that's not the norm. > why not write a few modules for some other people? See above. It's a mistake to generalize from young and/or small projects to those that have become large and…
On every project that I have worked on, developer support for projects increased with the amount of users.
I would understand if there was no one using this project and it was a one-person operation, but if you are getting so many requests that it is literally impossible to comply with the top 5% of them then you should have made friends with enough people in your community who would be suited for doing these tasks.
Don't get me wrong, I am not saying do every single request and I am definitely not saying spend most of your time doing requests. But my the developers admission, "Taskwarrior [...] is easy to programmatically convert to any other data interchange format."
If it would make that many people happy, to the point where you need to have a link handy to tell them "no", then it might be worth it just to write the feature that everyone seems to want, even if it is in an optionally usable format like a 'module'.