Exoplayer: Repository not contribution friendly

[benjamingr]

* ISSUES THAT IGNORE THIS TEMPLATE WILL BE CLOSED WITHOUT INVESTIGATION *

Issue description

Sorry if this sounds like a rant - I haven't interacted with ExoPlayer from a contribution perspective before.

The current repository issue system is a bit harsh. Opening issues looks intimidating and contribution feels very unwelcome.

I'm a video engineer and I want to make a contribution in some fields in Exo (namely, the ABR logic and some HLS features/bugs I run into).

I get that it's __very__ annoying to get people to stop opening support requests on GitHub. (So much, that I've even asked about it). I maintain a few big open source projects and I get how frustrating the stream of incomplete or nonsense requests can be.

(I recommend not providing support on GitHub at all, and redirecting users to more appropriate channels such as StackOverflow, a forum or an IRC channel - where the community can answer most of the questions).

I also think that locking issues makes discussion very unwelcoming. I think that locked issues indicate that discussion has exhausted itself (while often in ExoPlayer - issues I've run can use an update due to a new version or changed APIs).

I'd love it if there was way for video engineering professionals to get more involved. I love using ExoPlayer and the company I work at has a nice history of contributing to open source projects like hls.js.

I'm opening the issue here to make it open for discussion - but if you feel strongly about it I'm willing to discuss contribution in private. Of course you don't owe me anything so if you feel strongly about keeping the current contribution system feel free to say so and close it (I'll be disappointed but not angry or insulted, promise).

[ojw28]

We don't mind people asking questions here, provided they've made some effort to answer it themselves (if you can type some keywords from the question into Google and the answer is right at the top, that's pretty annoying). What's annoying are issues that provide none of the information we need to help (things along the lines of "tried to play a video, didn't work"). We've gradually made our issue template less friendly in an attempt to try and reduce these. Whether it's worked is questionable. If it hasn't, you're right, we may as well make the template more welcoming again (we should check this).

A few specific things:

• We do welcome sensible questions and high quality contributions that align with the project's direction, particularly from video engineering professionals. So you're more than welcome (i.e. encouraged) to send things our way ;).
• We automatically lock issues after a certain period of inactivity (I think ~4 months) because the vast majority of responses after such periods were observed to be low quality and unrelated to what the original issue was about. They're not useful, and make the thread harder for everyone else to read because they suddenly diverge into something else. If you want to ask a question about a locked issue, open a new one that references it.
• Quite a lot of the questions asked here could be answered directly by better (non-javadoc) documentation. This is our own fault, and we're working on it.
• We would really like it if GitHub were to support structured issue templates with required fields. That would provide a much better and more friendly way for us to prompt users to give us the information we need (e.g. "ExoPlayer Version" as a required field). We've thought about disabling the GitHub issue tracker and using Google Issue Tracker (Buganizer) instead, which does support this, but have opted not to do so for now.

[benjamingr]

Thanks for the response and explaining why things work the way they do.

We don't mind people asking questions here, provided they've made some effort to answer it themselves.

I believe that there are ~650 people who get pinged whenever anyone has a bug in their code and they open an issue - that makes following development discussion much harder. At bluebird when these started coming daily we added:

(This issue tracker is only for bug reports or feature requests, if this is neither, please choose appropriate channel from http://bluebirdjs.com/docs/support.html)

Which helped. Although moving the issue tracking for development to Google's bug tracker can also work (but has been less optimal in other projects in the past).

Quite a lot of the questions asked here could be answered directly by better (non-javadoc) documentation. This is our own fault, and we're working on it.

If you'd like, it would be an interesting place to start getting contributions in from the community and ExoPlayer's large user base. If you break this down into a task with smaller subtasks I'm sure a lot of people would love to take a stab at improving the docs and adding examples.

We would really like it if GitHub were to support structured issue templates with required fields. That would provide a much better and more friendly way for us to prompt users to give us the information we need (e.g. "ExoPlayer Version" as a required field). We've thought about disabling the GitHub issue tracker and using Google Issue Tracker (Buganizer) instead, which does support this, but have opted not to do so for now.

Google's issue tracker is a lot harder for new people to use in my experience and interaction on it is non-obvious (I have no facts to back this up though). I think the fact the issue tracker is used for two things (dev stuff like feature requests and bug reports and questions) makes things a lot harder.

You can opt for a StackOverflow tag and monitor it, or open a "non-fast-response" gitter - basically anything that doesn't bucket people who want to help technically with the project and people who ask support questions :)

[ojw28]

I believe that there are ~650 people who get pinged whenever anyone has a bug in their code

I don't think this happens, although I'm not sure what you're referring to exactly. What is the group of ~650 people that get pinged when someone opens an issue here?

[EDIT] Oh right, presumably people who are "watching" the repository.

If you'd like, it would be an interesting place to start getting contributions in from the community and ExoPlayer's large user base. If you break this down into a task with smaller subtasks I'm sure a lot of people would love to take a stab at improving the docs and adding examples.

We have internal people who can assist with this too, and we already have a breakdown of what we want to write. I think we need to do it in a centralised way, at least to begin with, to ensure consistency and that we're documenting what we want to document within each article. It may make sense to open it up more once we have some initial documentation and structure in place.

[benjamingr]

Ok, thanks for clarifying everything - I'll try to take a stab at the ABR mechanism and I'll write down issues as I run into them and include them in the PR (assuming I get it to actually perform better).

[ojw28]

Re pull requests: There's no way for us to advise whether something aligns with other work we're doing without knowing what it is, so if you're going to spend a significant amount of time on a pull request that you wouldn't be doing otherwise, it's generally a good idea to share a proposal early (e.g. as an issue that we can mark with the enhancement tag). This helps to reduce the probability of spending a lot of time on something and finding out later on that it doesn't fit. So please do that if it makes sense for your case. Obviously if you're going to be doing the work regardless of whether the pull request is accepted then the risk of wasted time is much lower, and it might be easier just to proceed and send a pull request when done.