> In an ideal world with infinite resources, there would be no need for
> this app.
>
> But in any successful software project, there's always more work to do
> than people to do it. As more and more work piles up, it becomes
> paralyzing. Just making decisions about what work should and shouldn't
> get done can exhaust all available resources. In the experience of the
> maintainers of this app—and the hundreds of other projects and
> organizations that use it—focusing on issues that are actively affecting
> humans is an effective method for prioritizing work.
>
> To some, a robot trying to close stale issues may seem inhospitable or
> offensive to contributors. But the alternative is to disrespect them by
> setting false expectations and implicitly ignoring their work. This app
> makes it explicit: if work is not progressing, then it's stale. A
> comment is all it takes to keep the conversation alive.
https://github.com/probot/stale#is-closing-stale-issues-really-a-good-idea
This file add the configuration needed for stale issues and pull requests
to be automatically closed. Defined as follows:
- issues and pull requests with no activity for 270 days will be marked as "status: stale";
- after that, there will be a period of 90 days for the issue or pull request to be claimed, otherwise will be closed.
The bot will never interact/close with issues and pull requests marked as:
- status: vetify
- status: accepted
- target: security
- type: discussion
For this setup to be effective, add https://probot.github.io/apps/stale/
to BigBlueButton repository.
Shave off the number of calls in video-preview and video-provider by
using a stream storage
We don´t call an upfront gUM in video-preview anymore to lift the
fingerprinting barrier on device labels and IDs. Flow has been reversed:
upfront enumerate, load first preview, then check if previous
enumeration was obfuscated.
Add a stream storage in video-preview`s service to avoid re-fetching
them in video-providerj
Remove some unneeded video-preview container props
Improve some of video-preview`s error locales
Here's what we do when user activates mic:
1 - When we do something similar to listenonly's joining process
until we find a valid candidate-pair. The information about this
local candidate is store.
2 - We then start a new userAgent, and as soon as browser finds
a candidate with the same local ip address, we leave only this
candidate in the SDP and send this to FreeSWITCH. SDP should
contain only a single candidate.
3 - The rest of signaling process is basically the same.
