Establish firm policies for this repository

There are currently 1000+ opened issues and counting. If there is to be any hope of getting this repository back under control, a firm and strict policy for issues is needed. Let's discuss that here, and based on conclusions develop a write up.
Once the policy is defined, opened issues that don't comply will be closed.

As a starting point (this is, of course, open for discussion):

- Questions of type "How do I..." or "Can you please help me with..." or "Can the ESP do..." won't be handled here. Such questions should be directed at a discussion forum, like esp8266.com or stackoverflow. All issues of this type will be closed with a simple reference to the policy. (example: how do I connect to wifi)
- In a similar manner as before, issues that are obviously user error, programming language errors, lack of knowledge/experience with the use semantics of the core libs, or similar, will be closed with a reference to the policy (example: my sketch crashes. There's an char[] in it that is not null terminated. exmple: trying to use yield/delay, or libs that use yield/delay, from inside async callbacks.)
- Issues about topics already handled in the documentation will be closed in a similar manner (example: can't flash with error espcomm failed)
- Issues must be provided with a minimalist sketch. Issues with an incomplete sketch, or a huge sketch, will be closed. Maximum effort must be put forth by the person opening the issue to reduce the relevant code that reproduces the issue, so that investigation can be taken up.
- Issues with accompanied investigation that shows the root of the problem should be given priority
- Feature requests that are accompanied by a PR should undergo peer review. IF the request is accepted, the PR should then be updated based on feedback, then merged.
- Feature requests that are not accompanied by a PR:
* could be closed immediately (not accepted)
* could be closed after some predetermined period of time (left as candidate for somebody to pick up)
* could be accumulated in a feature request list
Such feature requests should in general not be targeted for a deadline or release.

I would like to know who are the developers that are still active. I would also like to know of any potential developers who are interested in contributing. How can we get more people involved?

Questions that come to mind:
1. What is the current policy for maintaining compatibility with Arduino? Example: any lib contributed, do we case if it's specific to the ESP8266 and is not compatible with other boards?
2. How should IDE-specific issues be handled?
3. How should other build systems be handled, if at all? (PlatformIO, command line make system, etc)
4. How should releases be handled? Do we want releases at regular intervals, or do we want specific milestones to be reached?
5. How should new espressif SDK features/fixes be handled? Do we want to migrate asap?
6. Is there a policy for locking issues after closed? Should there be?

@igrr thoughts? Who else should be brought into this discusion?