There should be no guilt on either side. Sometimes putting time into investigating the stack trace isn't worth it for the user. However, reporting it still a good idea because the developer might recognize a regression or another angle at a bug being already experienced. If not, it's not a big deal to dismiss.
I don't agree. The reporting party should feel guilty about not putting effort into providing system information and troubleshooting further and reporting their findings. This is exactly why Stack Overflow works so well: low quality questions are downvoted mercilessly, and closed if they aren't improved within a short time period. It is also why automated reporting tools provide a good amount of contextual information along with the error and stack trace.
Furthermore, not including a description of the issue along with the stack trace makes it impossible for other users to determine if they are experiencing the same issue or something else (since it is possible for two different bugs to produce the same stack trace, or even the same error message).
I suppose this is true, but in my experience a low quality bug report is usually either user error or not familiar to the developer. In both of those cases more investigation would help, and often the user corrects him/herself. Only in rare cases does the developer have a magic fix for a (not even formatted) stack trace.
Opensourcing a project that becomes popular induces guilt, because it needs your time and attention to thrive, but you can't afford to give it, especially if you're interested in creating other things.
This claiming "clickbait" trend is getting out of control. It's like teenagers using the word "random" as a catchall term for who-knows-what.
By definition, the title of a talk given at a conference can't be clickbait.
Furthermore, how can you claim the title's content wasn't represented until 20 mins in? The title has two parts, one of which you seem to completely ignore.
Conference talks are typically associated with a descriptive title and an abstract that expands upon it. It's not uncommon for some to title their talks to generate interest at the expense of being appropriately descriptive. This is such a title, and the text associated with the video does not serve as an adequate abstract.
The "why do I feel so guilty?" portion of this title does not efficiently convey the content of the talk and instead preys upon the reader's fear, uncertainty, and curiosity. When we read this title we say to ourselves, "Hey, I use/make open source software! What should I feel guilty about?". This does generate interest, but at the expense of being less descriptive than a more prosaic title would have been.
If I were at a conference and saw this title without an abstract, I'd consider it unprofessional. It really is "clickbait" in the truest sense of the word, only that "clicking" in the context of a conference takes half an hour of my time and might prevent me from attending another talk that I would have been more interested in, had I not been led astray by an intentionally seductive and vague title.
It is entirely appropriate to call this title "clickbait".
If the title of your post is a question then by definition it's clickbait. A more reasonable title would be, "The open source community and the pressure of being part of it."
That simple rhetoric for some reason makes you salty does not make it "unreasonable." And using a title to ask a question predates "clickbait" by thousands of years.
Which is a strange concern because the solution is obvious: if the project is popular, it should be easy to find someone else to pass on the leadership position to and move on to other things.
The only guilt should come from just straight up abandoning the project. Unfortunately the open-source world is chock full of those.
Why should someone feel guilty because they made something, shared it to the world, but one day realized they didn't want to or couldn't continue to maintain it?
To suggest I should feel guilt for admitting I can't maintain all the personal code I've opensourced for other users suggests I ought to have kept it closed source, which seems like a net loss all around.
Indeed. I made a project a few years ago and maintained it for several years. At one point I just didn't have the time (or motivation, I suppose) to continue updates and essentially abandoned it without much official word, while putting in a good amount of work every few months. The guilt was pretty crushing, so I can understand where the author comes from.
Fortunately, someone offered to take it up recently so I feel much better now.
This is one of those situations where it would be great to have slides detailing points of the video. His are just drawings of some people's names and time points. I love the retro, sketch-style art but it doesn't tell me a thing. Several minutes in of rambling and I still don't know what it's about. Click the little X...
So, out of thousands of vids on the net on OSS or programming... each 20+ min long... why watch this unless I'm already a fan of the authors work? Not even critiquing the presentation as much as saying: give us a matching article or slides that lets us determine if we really want to watch the video. If it strikes a chord, people watch the presentation. Otherwise, most will just skip it and miss out on any gems it might have had. And that's a rational decision given the flood of info on the web.
This applies to a ton of videos rather than just @fat's. Anyone having to do a lot of research or want to get most out of their time relies on summaries. People not doing them are reducing impact of their own work.
I enjoyed it. The entire talk isn't about the history of open source - he eventually gets into issues about maintaining open source in modern day on GitHub.
It's a talk at a conference; it's not designed to be a web video talk. In context, those slides are fine - it's a lightweight entertainment talk about FLOSS history and opinion.
Scroll through until you see a slide about cute puppy syndrome (I think that was what it was called). You'll miss the buildup and the fun presentation of open source history but that's the key part of the talk. To spoil it slightly, it's about the lifecycle of open source projects.
Didn't see this one when I posted my other two comments. So, that's three comments that do a bit of what author didn't. Merging them together mentally gives me an idea of what to expect. Even an abstract saying about the same as you did would've been nice.
This sounds like a good article (from the title), however my company seems to have bulk-blocked the .xxx TLD. Out of curiosity, why did you put your blog on the .xxx domain?
Unless you are talking about open-source boobs, or something. Then I understand completely.
30 years ago .com may have been intended specifically for commercial purposes but that is buried underneath three decades of use as a generic catch-all TLD and as such using it communicates almost nothing about the site in question.
.org is by convention and usage largely reserved for nonprofit organizations. As such use of .org (intentionally or otherwise) communicates that the website in question is for a nonprofit.
xxx is, at merely 4 years old, brand spanking new. There hasn't been time for intent and practice to diverge meaningfully, ergo it's perfectly reasonable to assume a site that uses the .xxx tld is in fact a porn site.
pretty sure the only point of the .xxx TLD (aside from it being yet another source of income for ICANN of course), is that it clearly signals that the content is NSFW. It is totally reasonable for certain organisations to block it.
While you are technically correct, the term has an exact meaning in internet culture.
The term "safe for work" refers specifically to a lack of sexual and...medical... content. Looking at cat pictures might get you fired, but it's still "safe for work".
https://github.com/mizzao/meteor-autocomplete/issues/98