4 ms·

Thanks for comment. I generally agree with you, that I should now check what is available in the Handbook and submit patches to make it better but I have very u

Thanks for comment. I generally agree with you, that I should now check what is available in the Handbook and submit patches to make it better but I have very unpleasant memory from the past. There was time when VirtualBox was not available on FreeBSD, no one even thought about writing Bhyve and QEMU was only 'virtualization' option on FreeBSD (with KQEMU accelerator module). As I used FreeBSD I even made a howto - HOWTO: QEMU on FreeBSD - still available here: https://forums.freebsd.org/threads/howto-qemu-on-freebsd.175/ https://forums.freebsd.org/threads/howto-qemu-on-freebsd.175... ... and someone suggested just that, to add my thoughts/changes to the FreeBSD Handbook. ... so I did sit down and rewrite entire 'Virtualization Chapter' in HTML, still available here: http://www.strony.toya.net.pl/~vermaden/FreeBSD-Handbook-Virtualization.htm http://www.strony.toya.net.pl/~vermaden/FreeBSD-Handbook-Vir... ... and no one done anything with it. It was not merged, not a single bit from it was merged into the FreeBSD Handbook. When I asked why I got response that maybe if it was in the correct format (I do not remember which documentation framework FreeBSD used back then) some parts would be used but as its in HTML no one will even 'waste' time merging it. I did the most 'hard' part which is creating the valuable content, formatting is secondary thing for me, but it was not for them. Since then I do not bother about FreeBSD Handbook. I still use it from time to time thou. I would not have anything against even if someone would put my entire article there without any changes, that would serve a lot of people, but if someone will do it, that I do not know. Regards.

wk_end 8y ago
Without meaning to offend or diminish the work you did, I want to defend the FreeBSD project here. Consider the code version of what you linked above. Imagine submitting a patch in the form of an HTML post on a private website (wrong format), in poor and non-idiomatic style (both for the project and the language itself), full of typos and grammatical errors (bugs?), with the author themselves professing that it's "nowhere near finished". If someone submitted a patch to any serious open-source project in this form, they'd tell you in one way or another to come back when your patch was finished and was written in accordance with the standards of the project. You haven't done most of the hard part at all: you're complaining about their lack of gratitude for the beautiful lamb dinner you've cooked for them, but really all you've done is dump a lamb on their doorstep and expected them to shepherd it, slaughter it, and prepare it. (there's a flip-side to this: while the original comment you're replying to is right that (properly) contributing to the official documentation is the best way to support it and better than writing up a blog post, it also presumes that we all have the time or energy for that kind of commitment, which is much greater than that for just writing up a blog post.)
- vermaden 8y ago
  It was long time ago and and today it would probably look better but still zero response is not a good sign either.
  - rleigh 8y ago
    Volunteer time often means that if something isn't immediately actionable, or actionable with minimum effort, it gets ignored, and then it gets forgotten. It's not malicious, it's just the reality of things. If you had obtained the handbook from version control, and added this as a new file using the markup language in use, made sure it built without warnings or errors, proofread the HTML and PDF output, and then sent that in as a patch, it would have been mergeable with no effort other than a brief review. If the people reviewing it also had to completely rewrite it in the correct markup language, and they are not domain experts in the material it is covering, then you've basically given them a task which is hugely demanding upon their time. I've had several experiences of this. Sometimes it pays to pull all the stops out and spoonfeed the recipients with something which is as perfect as it can be, and they have no reason not to merge it. It takes a lot more time on the part of the submitter, but that's time you've saved the reviewer, by giving them a finished article. This can greatly improve the chances of success, by removing obstacles which would hinder it.
    - vermaden 8y ago
      Thanks, I will try that path then.
      - oh5nxo 8y ago
        Just as random someone who likes reading your posts, maybe there's a third way: An appendix in handbook that links to blogs like yours. I see that there already is "an aggregation feed of dozens of blogs" linking to planet.freebsd.org which does not respond :)
        vermaden 8y ago

wk_end 8y ago

Without meaning to offend or diminish the work you did, I want to defend the FreeBSD project here. Consider the code version of what you linked above. Imagine submitting a patch in the form of an HTML post on a private website (wrong format), in poor and non-idiomatic style (both for the project and the language itself), full of typos and grammatical errors (bugs?), with the author themselves professing that it's "nowhere near finished". If someone submitted a patch to any serious open-source project in this form, they'd tell you in one way or another to come back when your patch was finished and was written in accordance with the standards of the project. You haven't done most of the hard part at all: you're complaining about their lack of gratitude for the beautiful lamb dinner you've cooked for them, but really all you've done is dump a lamb on their doorstep and expected them to shepherd it, slaughter it, and prepare it. (there's a flip-side to this: while the original comment you're replying to is right that (properly) contributing to the official documentation is the best way to support it and better than writing up a blog post, it also presumes that we all have the time or energy for that kind of commitment, which is much greater than that for just writing up a blog post.)

vermaden 8y ago
It was long time ago and and today it would probably look better but still zero response is not a good sign either.
- rleigh 8y ago
  Volunteer time often means that if something isn't immediately actionable, or actionable with minimum effort, it gets ignored, and then it gets forgotten. It's not malicious, it's just the reality of things. If you had obtained the handbook from version control, and added this as a new file using the markup language in use, made sure it built without warnings or errors, proofread the HTML and PDF output, and then sent that in as a patch, it would have been mergeable with no effort other than a brief review. If the people reviewing it also had to completely rewrite it in the correct markup language, and they are not domain experts in the material it is covering, then you've basically given them a task which is hugely demanding upon their time. I've had several experiences of this. Sometimes it pays to pull all the stops out and spoonfeed the recipients with something which is as perfect as it can be, and they have no reason not to merge it. It takes a lot more time on the part of the submitter, but that's time you've saved the reviewer, by giving them a finished article. This can greatly improve the chances of success, by removing obstacles which would hinder it.
  - vermaden 8y ago
    Thanks, I will try that path then.
    - oh5nxo 8y ago
      Just as random someone who likes reading your posts, maybe there's a third way: An appendix in handbook that links to blogs like yours. I see that there already is "an aggregation feed of dozens of blogs" linking to planet.freebsd.org which does not respond :)
      - vermaden 8y ago