Codecov Report

Merging #1838 into master will increase coverage by 0.81%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1838      +/-   ##
==========================================
+ Coverage   50.18%   50.99%   +0.81%     
==========================================
  Files         236      238       +2     
  Lines       13993    14090      +97     
==========================================
+ Hits         7022     7185     +163     
+ Misses       6971     6905      -66

It might be worth creating different issue templates (you can have one per issue type) instead of having the check boxes. Maybe just one checkbox to say that they have read the guidelines.

@beardypig That's a good idea, I'll have to see if you can make an issue template (since for multiple it has to go through the GitHub interface as far as I'm aware), and the existing one remains as a fall back.

@gravyboat, to do it I think you need to make a .github/ISSUE_TEMPLATE/ directory, then in there you can create Bug_Report.md, Plugin_Request.md, etc. You can give them a bit of a YAML header (front matter) which has stuff like

---
name: Bug report
about: Create a report to help us improve Streamlink
 
---

Then it's just regular markdown. Unfortunately I cannot find anything in the GitHub docs for the issue template front matter...

@beardypig That's a good idea. I'll work on a new commit to convert over to that. I'm also thinking I'll have a stripped down ISSUE_TEMPLATE.md in the root which should be picked up if one isn't selected but that will mostly point people to use the templates. I couldn't find any details regarding the front matter either past what you noted.

Let me know what you think of this one. @back-to and @bastimeyer I'd like your feedback on these as well in the event you think I missed anything.

@gravyboat if you merge this in to your forks master branch (or change the default branch to this one) then we can see what it looks like :)

@gravyboat

Changes are looking good so far. There are a couple of cases where I would change the punctuation, but that'd be rather nitpicky. If you want, though, I can post my suggestions. 😅

I would also change the links (eg. contrib guide) so that the URL doesn't appear and the text is being used as link instead. It's just shorter and basically looks the same in markdown.

We should also discuss if it'd be better to add HTML comments (<!-- text -->) for the text that should be removed by the user. It's usually a good indicator if the person took the time and read it, but if it's too much that can be left by the (careless) user, issues can get really big and confusing. HTML comments are being kept by GitHub and will be invisible after being submitted.

Another change could be removing the already checked list item and turning it into a tier-2 header (##), like ## Bug report / ## Feature request / ## Plugin request.

Maybe we should also think about splitting plugin requests and plugin issue reports, as broken plugin are usually falsely being reported as regular bug reports.

Oh, and please do what @beardypig said when you get the time and change the default branch on your fork and enable issues, so that we can see it. Thanks!

@beardypig Done and done, I forgot that I disabled issues for the fork: https://github.com/gravyboat/streamlink/issues/new/choose

@bastimeyer Post away, I'm always happy to discuss punctuation (quick edit here, let's wait till I have the next pass ready to go, then we won't waste time after I make changes). The reason I posted links instead of text is because the links don't render inside of the issue window, only when you go to the preview, and since you can't edit in the preview mode I figured it would be more obvious to people to have direct links instead of the (oddly if you aren't familiar with markdown) text style linking, that can easily be changed if you don't agree with that though.

I like the idea of adding a text header and noticed that in a few of the example issue templates I looked at yesterday, I'll modify it either today or tomorrow to swap to that style of formatting and we can review it again.

Tier 2 header is a good idea. I'd like to leave in the unchecked item for the "have read the guidelines" item.

I agree with splitting plugin requests and plugin issues, good idea.

The repo is merged to master and issues are enabled so that's all set to go.

I think HTML comments around the text to delete would be nice, it’s a pain seeing all the issues with the text left... :)

@beardypig Yeah I'm going to add those and remove the note that the text needs to be deleted.

@gravyboat Maybe a template for questions should be added here as well. It would be useful for asking the submitter to specify their OS, configuration, etc.

@bastimeyer Do you mean a list of items instead of simply asking people to provide those details? I have them in the question, but I guess some people might not read that. Let me push my changes up.

I totally forgot about the general / fallback issue template... It is however not asking for any details at all, so yeah, maybe not a list, but just a simple sentence to make one add their details to the question if needed... It's always cumbersome asking for this if it's missing in the original post of a question.

@bastimeyer Alright I'll add some basic questions for the default/fallback template.

@bastimeyer Good review. I will try to get to these today. The only thing I may not do is use so many exclamation marks as I've noticed some people see that as being aggressive/rude. When I update them we can review it again.

maybe also another rule

Sites which are unmaintained.

Example #1835
Frontpage has links to 404 streams

Good point @back-to, I'll add that to the list.

Okay I think I got everything @bastimeyer, thanks for the feedback. @back-to I added that note about sites which are unmaintained. These changes are merged to master on my fork if anyone wants to take a look at them there: https://github.com/gravyboat/streamlink/issues/new/choose

Some templates still have the line at the top. Other than that, I think this is good to be merged.

Any other feedback on this? If not let's get it merged so people have to start filling out issues correctly.

One more comment... Where it says to include debug logs, there should be a note to say that --stream-url will suppress the output log. That option should be removed to get the logs. A few people have done this before.

Good suggestion, I've added that.

Yeah, agreed. @gravyboat, is this good to merge?

@beardypig Yep it's ready.

Thanks for sorting that @gravyboat :)

How did the decision to ban NSFW plugins come about?
In #1837, @back-to states "in #1763 were mentioned: […] • NSFW sites", but I can't seem to find anything relating to NSFW content in that issue — it seems to just be about piracy and re-hosting streams.

I'm worried this will encourage forks when users decide they need to re-add NSFW site support, which will cause confusion and draw developer power away from the "main" streamlink implementation.

@n-st It came about from discussion in a few different issues actually but here were the main reasons:

• We were getting a lot of requests for every NSFW website under the sun, to the point where a significant percentage of open issues and plugin requests were just NSFW sites. These issues/requests were almost always extremely low quality
• NSFW plugin users were asking tons of questions and generating lots of issues related to recordings, sites not working, etc.
• NSFW plugin users were abusive towards contributors and maintainers for no reason
• Several maintainers/contributors didn't want to work on a project that was potentially shifting towards NSFW sites as the main draw of the software

If people want to fork and add support for NSFW sites they are welcome to do so as almost no one requesting these NSFW sites was contributing so the loss is minimal. There are already applications out there for many of these NSFW sites, and side-loading plugins is quite easy if people want to do that (we didn't even scrub them from the history of the repo so they're still easy to get if people want them). It's just not something we're going to spend the energy of our small team on since our time is so limited, the users of these plugins treat us poorly, and we don't want Streamlink's main focus to become NSFW sites which was a real potential with how many people were asking for these plugins.

@gravyboat Thank you for explaining the background.
I was concerned that such a significant change in policy would have come out of the blue, but this makes the decision understandable.

No, it doesn't make it understandable.
What is the problem ignoring webcam users non-contributors, or explaining the situation to them?
One developer that left was worth more than webcam users non contributors.

@johnthecracker eh? I don't follow.

I see that plugins are getting removed.
Somebody made an effort to contribute with his knowledge and plugin and gets his work removed.
I personally use only filmon plugin from all streamlink plugins if it is worth saying
and talking about content.
To talk names, why did Rosadin leave?
Remembering his old posts I figure out why.

#1357 (comment)

@johnthecracker Sometimes that happens unfortunately, their commits still exist as part of the repo history however. Regarding Rosadin's departure they created an issue regarding that: #1992 and stated it was for personal reasons. It doesn't really matter why and it's not our business to pry into their personal matters.

I am surprised that I get so say it cool response from you.
I would expect it to be more critical.
So far so good.
Here is one constructive proposal from Karlo:
If I was asked johnny what clever do you have to propose, I would post this link:

#2003 (comment)

https://github.com/streamlink/streamlink/blob/master/CONTRIBUTING.md#pull-requests

By submitting a patch, you agree to allow the project owners to license your work under the terms of the BSD 2-clause license

https://github.com/streamlink/streamlink/blob/master/LICENSE

https://github.com/streamlink/streamlink/blob/master/CONTRIBUTING.md#plugin-requests

We reserve the right to refuse to implement, develop, or update any plugin. In addition we may remove existing plugins at our own discretion.

A plugin removal simply means that it won't be supported anymore and that it won't be included in future releases. If you want to continue using a removed plugin, feel free to browse the repo history and sideload it, there's nothing which prevents you from doing that. And if you want to continue developing it and re-releasing it in a Streamlink fork, it's also fine, as long as you don't break the license.

The removal of NSFW plugins from Streamlink was pretty reasonable though and @gravyboat already answered why the decision was made. If one feels like writing or maintaining code in their free time which gradually moves the project's focus into a different direction while also attracting more and more people who can't behave themselves and make maintaining the project less and less fun, then they can go ahead and fork. Having a secondary development branch for unsupported plugins wouldn't change this decline of quality.

I'm sorry to hear the toxic / abusive behavior towards the developers. I wish people could just be nice...

I think it's unfortunate that these plugins had to be force removed (overwriting existing plugin files with 0 length ones) instead of just being deleted and no longer supported (in which case an upgrade wouldn't remove them). But I understand...

I find the use of NSFW a little dishonest though. Since when is it suitable for work to watch twitch or any other streams instead of working? ;)
I would have used the word 'mature'/'adult' but I get it... (at least in the CONTRIBUTING.md it's clearly explained as "NSFW sites of a pornographic nature".)

I find it kinda weird that watching murder, blood, war... (in video games for example) is somehow acceptable (SFW) but watching love (sex) is not. Weren't there a "Make Love Not War" movement?
Maybe that's why people are so hostile, because that's shown as an acceptable behavior in media. But showing your own naked human body is somehow shameful...

Good luck and have a nice day everyone!