Project communication

[StringEpsilon]

I think we need to improve communication between maintainers, collaborators, contributors and users.

Specifically:

• Who can make a release and how was unclear and delayed 5.0.1 unnecessarily. That particular problem is solved now, but it might be time to update the CONTRIBUTING.md
• A lot of people are unhappy with how their issues are closed. I see the need for the default reply to stay on top of things, but making that message a tad friendlier with an invite to clarify might help a long way to reduce the resentments. (See also Error: Invariant failed, when react-router v5 export as webpack libraryTarget commonjs  #6770) [1]
• Some changes are / were poorly explained and or documented. Bringing back the changelog might help to address that particular problem.
• Communication about ongoing work is all over the place. We have the pinned timeline issue, Ryans blogpost, the Q&A on reactiflux, and various tweets. I'd expect all news to be communicated on this repository too.
• Additionally, the silence on Pull-Requests that introduce new features is demotivating. A simple "Things are in flux right now and we'll take a few months to get back to you" would do a lot.

The fact that the work on 6.x (or whatever version it will be) happens completely in the dark right now is also unsatisfying.

I'd love to contribute more than just bugfixes and simple optimizations. But I can't, because i don't know what's going on with the library right now. And everyone else either also doesn't know or doesn't talk about it.

As a result, the work on this repository often feels like all 4 mentioned groups working around or even against each other, rather than real collaboration. At least that's my impression.

---

See also:

• Release 5.0.1 #6739
• [meta] 5.0.0 changelog #6643
• #6497
• https://reacttraining.com/blog/reach-react-router-future/
• https://www.reactiflux.com/transcripts/ryan-florence/

---

[1]: Something like this might work:

The issue tracker here on GitHub is reserved for bugreports and feature requests. 
For usage questions, please use [Stack Overflow](https://stackoverflow.com/questions/tagged/react-router) or [Reactiflux](https://www.reactiflux.com/) 
where there are a lot more people ready to help you out. 

Please feel free to clarify your issue if you think it was closed prematurely.

Thank you for your understanding.

---

I'd also like to remind potential commenters that discussing individual people isn't the goal of this issue. And I remind everyone(!) to be respectful and civil. When it comes to communication issues, you have to be the change you want to see in the world.

[timdorr]

You're such a jerk, @StringEpsilon! /s

But more seriously, the Saved Replies feature is a per-person thing. So, we can't enforce it at the repo level. I'm happy to incorporate improvements to mine, but I can't make it Router-specific without having to also make others specific to different repos. It gets messy really quickly.

Here's what I'm changing mine to:

The issue tracker here on GitHub is reserved for bug reports and feature requests. For usage questions (which is what I believe this is), please use Stack Overflow or Reactiflux where there are a lot more people ready to help you out. Thanks!

Please feel free to reply if you think this issue was closed prematurely.

As for the release stuff, anyone with write access can make releases now. I additionally have the publish bit on the packages on npm, but generally don't like to do that because lerna publish makes me feel like I'm going to set everything on fire when I use it.

I do agree communication is scattered. Both Ryan and Michael's profession (React Training) is demanding from a time perspective, so communication from them is understandably hard to come by. I have noticed they tend to develop new releases privately before showing them to the community for feedback. While I understand that feels "gatekeeper-y", I do think it makes sense for them. We did an open development process for Hooks in React Redux that took over 2 months to really nail down. That was for just 3 new functions and no refactoring of existing code. And the only reason it didn't take longer is because both myself and @markerikson were fairly active during the process. If neither Ryan nor Michael have enough free time to devote to open source feedback work (which is more time-consuming than coding, IMHO), building a new version completely in the open is going to take years to complete. And given their experience with this stuff, I trust they have good ideas in mind. I'd rather leave them to their devices, rather than trying to cram too many cooks in the kitchen.

As for the changelog, that indicates that the Releases page by itself is not sufficient. But the fix is simple: do what we do on Redux and create a CHANGELOG.md file to point to the Releases page. We've never gotten complaints about it missing or being hard to find on that repo, and it is much larger than this one.

[timdorr]

Farts. Hit the wrong button there. Oh, the irony...

[timdorr]

OK, just make a changelog file: https://github.com/ReactTraining/react-router/blob/master/CHANGELOG.md

[pshrmn]

Issues are tough; everyone thinks the bug is with React Router, but it almost never is. A good percentage of the time the issues aren't even related to React Router. I used to provide some help, but the issues section really isn't the place to do that; everyone that watches the repo gets a bunch of pings because of a conversation that should happen elsewhere. Maybe it makes sense to setup a bot to warn people and encourage them to move their question to StackOverflow/Reactiflux?

To expand on what Tim said about private development, I'm sure that you've seen the "React Router changes its API every week" type of meme. That was exasperated with v4 dev when people were creating content (tutorials, etc.) about the v4 alpha, which was outdated almost as soon as it was created. That sort of negative feedback creates a push towards development in private; it isn't ideal, but it is where we are at. This does mean that RR is in a weird period where it doesn't really make sense to develop new features for v5, but there isn't much that Tim or I can do in that regard.

[StringEpsilon]

@timdorr I appreciate the changes. We could add it as a (non-binding) template to CONTRIBUTING.md

As for the changelog: Just the release tab can work, but only if the releases contain a full and proper changelog. The v5.0.0 entry is lacking in some peoples opinion - and mine. It directs the user to yet another page and the alpha and beta logs. If someone is willing to adjust the entry, I'll dig through the commits and write something up like I did for 5.0.1.

@pshrmn:
Well, I migrated from v3 to v4, so I got a good dose of that. And I understand that decision to an extend. However, I'm not entirely sure that it's the right move. Ultimately though, it comes back to communication. Just a quick "Hold your horses, we are working on things" is all I ask for.

@timdorr @pshrmn: I appreciate the work and time both of you guys put into this library the past couple months. Please don't take this issue personal, it's not meant to be.

[StringEpsilon]

I reconstructed a 5.0.0 changelog entry from the sum of the alpha changelogs.

Needs some more polish and checking for completeness. But it should be an improvement.

---

#Breaking:

* Since the old context API is no longer used, any access to the old context will fail. Use of the react router context is not supported, please use  `withRouter()` or a `<Route/>` instead.
* Due to the new context API, mixing of imports will now result in an exception:

```jsx
// Be careful, this won't work anymore!
import BrowserRouter from 'react-router-dom/BrowserRouter';
import { Route } from 'react-router-dom';

<BrowserRouter>
  <Route />
</BrowserRouter>
\```

Refactor as follows:

```js
// These are both from the same build and use the same context object
// so there won't be a mismatch :)
import { BrowserRouter, Route } from 'react-router-dom';
\```

* In development mode, we now throw an error when using 2 different builds (see b2c6fa0), i.E. combining CJS imports with ESM imports.


#Features:
* `<Route />` now supports an array of paths - #5889 (thanks @\baronswindle)

```jsx 
<Route path={["/BigApple", "/NYC", "NewYork"]} component={NewYork} />
\```

#Changes:

* `<Route/>` now supports multiple child nodes when using react >= 16.0.
* Migrated to new react context API, with a polyfill for react versions < 16.2
* Removed deprecated lifecycle methods `componentWillMount` and `componentWillReceiveProps`
* Introduced more warnings in development builds
* Changed build-process to rollup:
  - Smaller build size
  - Package now includes pre-minified files
  - Package now consists of single-file builds that include all modules.
* Upgraded to history 4.9.0
* Per file imports are deprecated and will be removed in a future major version. For now, a warning will be logged.

#Bugfixes:

* Made sure that react router conforms to react `<StrictMode/>`
* Fixed `<Link />` not working properly with target="_self" - #6138 (thanks @\ericyang89)
* Fixed <Route component> prop-type warning when using forwardRef - #6417 (thanks @\frehner and @\eXon)
* Added support for createRef in <Link innerRef> - #6567 (thanks @\gcangussu )
* Removed use of `eval` in development to be compliant with unsafe-eval CSP - #6611

#Other:

* Migrated to `babel-preset-env`
* Improved testing infrastructure to improve developer workflow
* Several docs improvements - #6410 (thanks @\justsml)

P.S. To avoid pinging everyone named in the PR, I put the whole think in a code thingymabop and added a backslash to be extra sure. I hope that's enough. :)

[timdorr]

I put that into the 5.0.0 release with some tweaks.

[mjackson]

I am going to try to keep this message short because I have a really hard time reading through lengthy posts here on GitHub. Lengthy posts that address too many points at once make it difficult for any real change to actually happen.

re: the changelog - I recently stopped maintaining the changelog because it is a very manual process. I originally hoped that we could get people to add to the changelog when they submitted PRs, but that didn't go as well as I hoped. So instead I started creating detailed release notes with each release. IMO this is better. I'd prefer to ditch the changelog completely and redirect people to the release notes.

re: closing issues - we have a bit of a unique problem here because the router is such a widely-used library, so our sample set is different. People who need help using the router should be redirected to Stack Overflow. Bug reports with minimal repros are ofc welcome.

re: collaboration on the next major - again, we have a unique problem here because the router is used by so many people. It's not good to get too much input too early in the process, and it can actually slow things down and cause a lot of uncertainty in the community, so we have to be very careful about how we communicate what is coming in the future. But we are communicating on our blog.

re: silence on pull requests - we should probably have a bot or something that auto-closes PRs that don't get any response within a certain time.

[mjackson]

re: stale issues + PRs - maybe we should add these:

• https://probot.github.io/apps/stale/
• https://probot.github.io/apps/no-response/

re: issues that are really just support requests, we should probably add this:

• https://probot.github.io/apps/support/

[mjackson]

OK, I added the stale + support bots in 6f1eeb5

[StringEpsilon]

@mjackson

re: But we are communicating on our blog.

Well, that' was kinda of my point. It's fractured. I posted the link to the latest blog post on the timeline issue - but only after I found it by happenstance. Posting it on the blog is cool, but this repo is where RR lives. I'm only asking you to coordinate the info here with the info on social media and your blog.

re: silence on pull requests - we should probably have a bot or something that auto-closes PRs that don't get any response within a certain time.

That's only gonna make it worse. Sure it makes the PR list nice and clean, but it makes the feeling of being completely unwelcomed even worse. Dead silence is far better than a bot rejecting your PR. Because that signals that you can't even be asked to politely answer the request and explain the lack of action or to reject / close it yourself.

Edit: And I think people generally understand that some maintainers happen to be super busy at times. So a lack of response is usually pretty accepted. But you still work on RR. Hence I asked you to let people who want to work on RRknow what's going.

(And sorry about me rambling on.)

[mjackson]

@StringEpsilon I do try, but I do not always have time to explain to people why their PRs will not get merged. Nor do I owe them the time or an explanation. My work on the router is purely voluntary. Auto-closing stale issues + PRs may not help those who create them very much, but it at least sets their expectations which IMO is better than them not knowing if anyone is looking at their stuff.

[StringEpsilon]

First off, I'm sorry that my previous comment was a bit heated. I violated my own rules and I don't have any defense for that.

I totally understand that any maintainer is a volunteer, and I respect that. This isn't about "owing" anyone anything. It's about being nice and nurturing collaboration. Or at the very least, letting people who offer their time and help know when it's not wanted.

You could even automate that, by letting the bot close all incoming PRs with an appropriate message.

Edit: I don't think I'm the right person for this debate.

[allankikkas]

good to know that you have a blog (i did not know that). please add a link to that blog to docs and readme file as probably a lot of devs don't ever visit your main site but there is a lot to read.