Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendered documentation for GitHub Pages #37

Open
maelle opened this issue Apr 14, 2020 · 5 comments
Open

Rendered documentation for GitHub Pages #37

maelle opened this issue Apr 14, 2020 · 5 comments
Labels
enhancement New feature or request

Comments

@maelle
Copy link

maelle commented Apr 14, 2020

I've just seen

# Some sites will return 403 if it's not a "human" user agent
and this is brilliant (the user agent setting)! What about listing the strengths of this library in the README?

@vsoch
Copy link
Collaborator

vsoch commented Apr 14, 2020

We could do that! Although I'm not sure pretending to be an actual user agent (and not a bot) is something that I'd want to show case, some people might not be happy about it. What do you think @SuperKogito ?

@SuperKogito
Copy link
Member

So I did not knew about user agents before and when I saw them for the first time, I was very impressed. I agree to @maelle point, the user agents option can be attractive to many users as it simulates a user behaviour, which makes the tests more realistic.

On the other hand, to @vsoch point: I think many websites won't appreciate the extra/unwanted deceptive traffic simulating users as this would make their statistics of Web browser usage inaccurate (User agent spoofing) and excluding bots won't disable the checks we run.

This seems to be a grey area so from what I see, we have 2 options:

  • Option 1: provide transparent documentation as this is a testing tool and users should bare the responsibility of any miss-use, but since we want to run continuous analytics, this can comes back to bite us :/

  • Option 2: not include this for now, and see how this develops in the future. Just wait and see, maybe do more research on the general practises for such tools.

As much as I want to go with the first option (since I am all for transparent good docs), I think we should go with option 2, at least for now.

@vsoch can you elaborate on what can go wrong here in your opinion? is it only what I mentioned or is there more to it?

@vsoch
Copy link
Collaborator

vsoch commented Apr 14, 2020

It's not super terrible, there are plenty of posts (e.g., this one) that talk about doing the same thing. I personally don't see the need to have bullets in documentaiton or a readme that say "This library is so great because" for functionality that isn't relevant for the user. For example, providing example recipes in urlchecker-action is important - the user needs to write a recipe. The user doesn't care about the user agent strings, they just need the tests to work. This is why I think it should be left out, not for some reason that we are doing something totally off base.

@SuperKogito
Copy link
Member

I agree. I would say most users will be interested in the library as whole (How to use it? Does it fulfil the task?) rather than its mechanics.

@vsoch
Copy link
Collaborator

vsoch commented Apr 14, 2020

So @maelle thank you for the suggestion - let's rescope to just overall improving documentation. We just have a github readme thus far, and at some point we can render something pretty instead.

@vsoch vsoch changed the title Better document strengths? Rendered documentation for GitHub Pages Apr 14, 2020
@SuperKogito SuperKogito added the enhancement New feature or request label Apr 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants