It's definitely not a good thing to break things, but I'd oppose the "not introduce Boostrap" point. It could be useful to have the Boostrap CSS files around, so if anyone will be adding/refactoring some code in templates, the old styling could be replaced piece by piece that way.
I doubt extra unused files will be maintained, especially if it not really is "ready" yet.
This feels like a false dilemma a bit - existing nice file vs. a new unmaintained file. The big advantage of Bootstrap is that it's very well documented and it consist from a lot of small reusable parts. You cant say any of that about the existing CSS file.
I think it will be hard to introduce bootstrap gradually; it will add a lot of css and change a lot of things immediately.
Both approaches (ie. introduce gradually vs. introduce by changing everything at once) have their trade-offs. As said above, I'd prefer to introducing it gradually for a couple of reasons:
It will need a lot of effort from a single person to replace everything at once. Doing such massive task without seeing any gradual progress can be demotivating. Let's say the task will follow the 80/20 rule. If the person will give up with 80% of the transformation done, the result will be nothing. On the other hand, if the transformation will be split into a series of smaller tasks, we'll get that 80% already.
It's also a bit annoying to do a code-review and testing for massive PRs, and every time someone will change CSS/templates while the PR will be opened (which can be quite a long time, as I can see the dates for the currently opened PRs), it will need to be merged, and updated.
My opinion is that as we've released recently, if there's someone ready to invest time and effort into Bootstrap stylin, we need to switch now to make sure that we don't have to rebase this branch endlessly as it seems there's little interest in fixing it while it's hanging around somewhere else.
I know @Mads Kiilerich insists the default branch should be kept stable, but given the interface is usable while not perfect this may be a reasonable thing to sacrifice if we fix it quickly (a couple of weeks, not a couple of months).
We are using the default branch in production and can't introduce regressions.
If there is a need for a temporary regression on a development branch, then we a development branch with a different policy than the current default branch - that might be two different branches. And I don't see much benefit from having the less stable development branch in the main repository. Do you?
The big question is of course how far it is from being feature complete and not constitute a regression. Is there a todo list?
Sorry, I am new here - if the default branch is for production, what is the stable branch for?
Anyway - if there will be introduced a new branch (let's say release/0.4.0), would this PR be accepted in there?
I would say that the main branch is for "as far as we know, ready for release at any point" while the stable branch is just that; "proven to be ready for release because it is as stable as possible, with only minimal lowrisk bugfix changes has been requested and made recently while no new features and unnecessary risk has been added".
IMO, andrew's repo/branch is a perfectly fine branch, almost ready for release. As soon as everybody (or a majority) agree it is ready for release, it should be merged to the default branch.
I'm sorry for being a jerk, but I hope we all can benefit from having a stable and tested product as a result of the conservatism.
Yes ... but any developer can also just create his own fork on bitbucket or his own Kallithea and work there, without having to wait for someone with upstream push access. the good thing about bitbucket self-updating PRs is that it automatically will move forward as new commits are made.
I think this PR is easier to find than a separate repo hosted under conservancy. I also think something that clearly is downstream can be much more informal and quickly make progress than something that is "official". I doubt that the name of the development repo is blocking any contribution.
Anyway, I am not a conservancy admin. If Andrew would prefer something like that, go ahead.