Live data from Hacker News

FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

taskwarrior.org

31–39 of 39 posts

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#31
post #27

I 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…

The scenario here is "The package is out of date, why have you not refreshed it yet." What should the Taskwarrior developers do to fix that? You suggest the failure is due to 'problems that make packaging difficult'. But perhaps it's the lack of an active package maintainer?

Perhaps. Automatically putting the onus on the developer would be wrong, but so is automatically putting the onus on the packager. It's a collaborative process. Blaming the packager represents exactly the same sense of entitlement that the author complains about among users demanding features. Packagers are often volunteers too, doing what they do in their spare time. Usually they're glad to push out a package for a developer who is doing their best to facilitate the process themselves, but blindly passing the buck doesn't fit that description.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#32
post #27

Earlier quoted context omitted.

The scenario here is "The package is out of date, why have you not refreshed it yet." What should the Taskwarrior developers do to fix that? You suggest the failure is due to 'problems that make packaging difficult'. But perhaps it's the lack of an active package maintainer?

Perhaps. Automatically putting the onus on the developer would be wrong, but so is automatically putting the onus on the packager. It's a collaborative process. Blaming the packager represents exactly the same sense of entitlement that the author complains about among users demanding features. Packagers are often volunteers too, doing what they do in their spare time. Usually they're glad to push out a package for a…

I believe I understand your point.

However, "What should the Taskwarrior developers do to fix that?"

Let's suppose I have a package, which I update quarterly, and I have a public announcements list, set up for people to be notified about new releases, and I answer support emails.

Someone sends me an email saying the version they get through Fink is a year out of date.

What is my responsibility as a developer? Do I contact the Fink maintainer myself? Or is it more effective for a user to ask for help?

I can totally understand the argument that I should track down these people and ask them to update the package.

But I can also understand the argument that I've set up an announcement list, and provide support, so what more do maintainers need?

Yes, the personal touch helps, and maintainers get little feedback or support. But at this point it isn't really "packaging" but "interfacing with third-party distributors".

You made the comment 'Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery,'.

Going back to my hypothetical, if all of the other package distributors are up to date (RedHat, Anaconda, Homebrew, ...) and only Fink is not, how does the failure with Fink show that I haven't learned all I can about software delivery?

Really, however, we don't know the history of why that comment is there. It could be that they tried several times to update their package until finally giving up. If that were true, then they "learned" it was best to let the package users demand updates, not the suppliers.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#33
post #30

Earlier quoted context omitted.

See https://news.ycombinator.com/item?id=11054268 . But in the end, I am not talking about the devops around the application. The only opinion that really matters there is the one coming from the project owner. Your obvious attempt straw-man is nothing but opaque. What I am attempting to discuss are features for the application that the owner refuses to implement because "get out". Had Linus said that to the first pe…

You say "see ...", but I've already commented on that comment. Your analogy with Torvalds isn't that relevant. Building an init daemon didn't conflict with the long-term goals, and the advantages are reasonably clear. Consider the FOQ "Why is Taskwarrior written in C++ and not something hackable". We can construct a similar question to pose to Torvalds - "Why is git written in C and not a more modern language like C+…

I will again re-quote myself.

"But in the end, I am not talking about the devops around the application. The only opinion that really matters there is the one coming from the project owner. Your obvious attempt straw-man is nothing but opaque."

I am simply addressing the section about the feature requests.

You on the other hand are painting my argument as something it is not about.

Edit: By features I mean anything under "Why Didn't You Implement My Favorite Feature?"

My comments are solely on that section.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#34
post #32

Earlier quoted context omitted.

Perhaps. Automatically putting the onus on the developer would be wrong, but so is automatically putting the onus on the packager. It's a collaborative process. Blaming the packager represents exactly the same sense of entitlement that the author complains about among users demanding features. Packagers are often volunteers too, doing what they do in their spare time. Usually they're glad to push out a package for a…

I believe I understand your point. However, "What should the Taskwarrior developers do to fix that?" Let's suppose I have a package, which I update quarterly, and I have a public announcements list, set up for people to be notified about new releases, and I answer support emails. Someone sends me an email saying the version they get through Fink is a year out of date. What is my responsibility as a developer? Do I co…

> I can totally understand the argument that I should track down these people and ask them to update the package.

You shouldn't even need to track them down. If it's a packaging and distribution channel you've used before, you should already be in communication with the package maintainer. Yes, it's possible that there could be a problem with a package you didn't know existed, but such cases are very much the exception. Even then, the right thing to do would probably be to suggest a better-supported alternative and/or introduce yourself to the people maintaining that package.

> It could be that they tried several times to update their package

It could be. We're giving rather a lot of benefit of the doubt to the developers, aren't we? Why not give some to the packagers? They have their own standards they need to maintain, for the sake of their users. As often as not, packaging delays are the result of developers just throwing stuff over the wall for someone else to fix up. We need to proactively fight against that tendency.

> they "learned" it was best to let the package users demand updates, not the suppliers.

Again, it's not either/or. Both developers and packagers need to be part of that conversation. Neither gets to walk away and say it's somebody else's problem. As always in open source, collaboration is critical.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#35
post #32

Earlier quoted context omitted.

I believe I understand your point. However, "What should the Taskwarrior developers do to fix that?" Let's suppose I have a package, which I update quarterly, and I have a public announcements list, set up for people to be notified about new releases, and I answer support emails. Someone sends me an email saying the version they get through Fink is a year out of date. What is my responsibility as a developer? Do I co…

> I can totally understand the argument that I should track down these people and ask them to update the package. You shouldn't even need to track them down. If it's a packaging and distribution channel you've used before, you should already be in communication with the package maintainer. Yes, it's possible that there could be a problem with a package you didn't know existed, but such cases are very much the excepti…

> Yes, it's possible that there could be a problem with a package you didn't know existed

My limited experience may well be the exception, but I'll bring it up anyway. I wrote an RSS module in 2003. Someone else later added it to PyPI, the Python indexer. It has also been distributed by multiple packaging systems. I had no clue. No packager has ever said anything about it to me.

Looking now, it's distributed by Gentoo, Debian, Slackware, Ubuntu, and more. It's also used in PyMediaRSS2Gen, dilbert-rss, and loads more packages.

It took me two days to write that package, and another few days of maintenance in the 12 years. Until now I believed this hand-off mechanism, mediated by PyPI, was the way to go. Because it would take me much longer to interact with all of those distributions than to write the code in the first place!

> Why not give some [doubt] to the packagers?

Because the statement you made earlier, "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." gave no doubt to the developers.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#36
post #19

Earlier quoted context omitted.

Not everyone knows how to program. If a programmer asks for a feature, tell a programmer to write it, if someone who is interested in programming help them write a feature, but if enough people officially request a feature it's better to just help the lot of them.

Thats equivalent to saying "if enough people have strong feelings about how you should spend your free time, you should listen to them". Would you really support that in any context that didn't involve "open source"?

Depends on how you interpret putting code online, and how it is done. If I started/declared a running club, there maybe expectations on how I spend my time - I initiated the expectation.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#37

Earlier quoted context omitted.

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.…

> On every project that I have worked on, developer support for projects increased with the amount of users. Cool anecdote, bro. Some projects are fortunate that way, but I'd say it's only those in the "Goldilocks" zone in which your user based overlaps significantly with average-developer skills. At one end of the scale, as another responder pointed out, the vast majority of people who care about your project will b…

Please don't be personally abrasive in HN comments. This post would be fine without the snarky swipe at the beginning and the personal swipe at the end.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#38
post #25

Earlier quoted context omitted.

Not everyone knows how to program. If a programmer asks for a feature, tell a programmer to write it, if someone who is interested in programming help them write a feature, but if enough people officially request a feature it's better to just help the lot of them.

I wrote a simple RSS package in 2003. I still get support emails about it. I don't even remember how the code works. I wrote some introductory Python code 10+ years ago, for one of my classes. I put it online. I now get random college students emailing me personally to ask for help doing their homework. I distribute some of my software for free. I've since had people demand (yes, demand) essentially hours of free sup…

When I was in college (15 years ago) I did a course on ancient Hellenistic religious groups. Part of that was to either write a 20-page term paper (on a topic assigned by the professor), or produce a smaller set of Web pages on the topic.

Being lazy, I spent a weekend teaching myself HTML, and did the Web option. It was linked from the course page on the college's site.

Ten years later I was still getting random emails from people who saw it, noted the .edu domain, and assumed I was an academic expert on Hermetic cults. Thankfully, a reorganization of the college's site and course pages seems to have killed it off for good.

Re: FOQ – Frequently Obnoxious Questions When Doing an Open Source Project

#39
post #25

Earlier quoted context omitted.

I wrote a simple RSS package in 2003. I still get support emails about it. I don't even remember how the code works. I wrote some introductory Python code 10+ years ago, for one of my classes. I put it online. I now get random college students emailing me personally to ask for help doing their homework. I distribute some of my software for free. I've since had people demand (yes, demand) essentially hours of free sup…

When I was in college (15 years ago) I did a course on ancient Hellenistic religious groups. Part of that was to either write a 20-page term paper (on a topic assigned by the professor), or produce a smaller set of Web pages on the topic. Being lazy, I spent a weekend teaching myself HTML, and did the Web option. It was linked from the course page on the college's site. Ten years later I was still getting random emai…

Do you (or archive.org) has that stuff archived? This sounds to be a cool thing. I'd like to read it if possible. (And I promise I won't mistake you for an academic expert ;) )
Post reply on HN