4 ms·

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
      Good idea. There is also FreeBSD Community Resources wiki page - https://wiki.freebsd.org/Community/Resources https://wiki.freebsd.org/Community/Resources - which contains links to such blogs and resources.
- tachion 8y ago
  In case of documentation PR's the doc team is openly accepting properly written (technically, grammatically and so on) plain text documents and takes the burden of writing the proper docxml patch on them, simply get in touch with them vi Problem Report or IRC or mailing list :)

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
    Good idea. There is also FreeBSD Community Resources wiki page - https://wiki.freebsd.org/Community/Resources https://wiki.freebsd.org/Community/Resources - which contains links to such blogs and resources.
tachion 8y ago
In case of documentation PR's the doc team is openly accepting properly written (technically, grammatically and so on) plain text documents and takes the burden of writing the proper docxml patch on them, simply get in touch with them vi Problem Report or IRC or mailing list :)