Better way to contribute to BlazorStrap

[chanan]

I am opening this issue to solicit suggestions from people that contribute to BlazorStrap. First, many thanks to everyone that contributes to BlazorStrap and I glad to have this problem!

Merging PRs to master is becoming painful. Today, I had the "pleasure" for the first time to see Github's web merge resolver and I never want to see that again... I think that to get around that we need to start working off of branches and not master. To that end, if any of you are used to the way other projects work and have suggestions, please list them here. Once we settle on something, I will create a contributing.txt with the guidelines.

Again, many thanks to everyone that contributes to BlazorStrap,

PS - If anyone has time and the desire to help out on a more permanent basis please let me know.

Tagging some people that have contributed lately: @IvanJosipovic @jbomhold3 @hez2010 @chucker @sitharus @BlackFenix2 @razfriman @Hawxy

[chanan]

So I think part of the problem was that I didnt have the Github extension for VS installed. Might be easier now

[Hawxy]

I took a quick look at the PR you ran into trouble with, and I don't think the issue has anything to do with pointing towards master. You're gonna have to deal with a merge conflict at one stage or another regardless of branch.

The simple solution is just to make it the pull requester's responsibility to keep the PR up to the date with the upstream master, and ping them to rebase it if needed.

Optionally, you could use something like GitKraken to one-click checkout the pull request and rebase it yourself so you're not waiting for the PR'er (and to avoid github's merge resolver)

At the same time, I would also suggest that you use feature branches and PR's for any non-trivial changes. You could merge in any pending PRs and then rebase your feature branch, thereby making conflicts easier to resolve and reduce the chance of a conflict appearing within a contributor's PR.

[chucker]

We definitely have a few conflicting concerns here:

1. Framework changes: Blazor itself is in early stages. It's not as rocky as last year, but almost every single release has required changes to libraries, including BlazorStrap. As a result, a significant portion of issues and/or pull requests is in fact nothing but "upgrade the project to work with the latest Blazor preview". I estimate this won't settle down until after the release of .NET Core 3.1 in November. (And maybe not before the release of client-side Blazor sometime next year.)

2. Bugfixes/feature completion: Some of BlazorStrap is still incomplete/broken/in flux at this point.

3. Additional features: Probably no need to explain, although there's some overlap between 2 and 3 (for instance, when the demo page says "Checkboxes and Radio aren't support yet by BlazorStrap", whether that's 2 or 3 depends on how we define the 1.0 milestone).

These are roughly ordered in how I think they should be treated in branches. 1 should certainly be merged to master, 3 should live on a feature branch for a while, and 2 is sort of in between.

I would start with a (simple) roadmap. Doesn't need dates. What constitutes feature completeness for 1.0? Will there be a 1.1 that adds more Bootstrap features like button-style checkboxes? What's the long-term 2.0 or x.0 goal?

[chanan]

@chucker Good idea on the roadmap. I will take a look again at the source - reactstrap and see if we have feature parity (its close but not quite). I have also been using react-bootstrap lately (https://react-bootstrap.github.io/) which is the same but some things are implemented differently to see if there are some good ideas there. Lastly, I would like to add or change forms and inputs to use the newer EditForm controls from Blazor. I will get some roadmap together soon

[chanan]

Going to close this. Will provide mentioned roadmap. Call out still for anyone that wants to help maintain BlazorStrap!