3 ms·
"Hey, your docs say that curl should be doing this, but it's not working for me?" <2 pages of back-and-forth posts later> "Oh you're using xCurl, yeah you nee
by Cogito 3y ago
"Hey, your docs say that curl should be doing this, but it's not working for me?"
<2 pages of back-and-forth posts later>
"Oh you're using xCurl, yeah you need to talk to Microsoft."
It probably depends on the reach this has within the intended audience (people wanting to deploy libcurl on Xbox?) as to how much of a support burden it will end up, but I suspect more than Mozilla has to deal with from similar situations.
- cxr 3y ago[flagged]
- Lukas_Skywalker 3y agoBut the comments are not the same? bawolff says it wouldn't be a problem to just link the curl docs. Cogito says it would, since users would just ask Daniel for help, thinking xCurl was the same as curl, despite them having different implementations. This would place a large burden on Daniel.
- cxr 3y ago[flagged]
- Cogito 3y agoThe point I'm supporting is that users will not realise that the documentation that is linked to is from a different project than the one being used. Hopefully, by focusing on an example of how a support interaction could go (clueless user, lots of back and forth before the key issue is identified), it shows how this practice is good for neither users nor for the curl team who will end up dealing with the fallout. I also address the MDN example by stating that I suspect the audience and reach of xCurl will create a larger support burden for curl than Mozilla would see in similar situations (aside: even though it wouldn't be reasonable in that case either!) Unless it's done very carefully, pointing users to the parent project's documentation will cause a support burden on that project, and that's just not reasonable for Microsoft to do in this situation.
- cxr 3y ago[flagged]