About the future of this repository

[Timvde]

Hi all,

I started this repository because I had the feeling somebody needed to step up and do it. Over the past year-and-a-few-months, I learned a few things:

• Requiring my extremely high quality standards on minor stuff like git history has been tough for contributors. Many people contributing know CSS a lot better than me, but don't know git very well. I got some remarks on this in the beginning, and I believe those people were right.
• This repository got way more popular than I initially imagined. While this is of course positive, I always wanted to test every piece of CSS by myself. I did find some bugs and blocked PRs based on them, even though they were, again, sometimes relatively minor. This also can be demotivating for developers, and testing on three platforms was also a lot of work for me, so I ended up losing my motivation too (as you probably have noticed).
• I even required specific code style for the CSS, without providing the actual linting or CI to check it. This also proved to be frustrating for many, and understandably so.

So, how would I like to proceed? I still think that this repository can have purpose for many, and seeing PRs arrive every now and then, I think I'm not alone. So I'd like to make this a real community repository that minimizes the work for me, and gives all of you more freedom. More concretely:

• I stop testing all code. It's on you. I trust you to test it yourself. If you want me to test it on a specific platform because you don't have access to it, I will, but you need to ask it.
• I stop caring about git history (for this specific project). I will keep using the "Squash and rebase" button, hoping that it will help, but I'm not going to do manual rebases anymore.
• Use whatever code style you want. I will leave the guidelines in the contribution guide, and I still encourage being consistent, but I won't block PRs on it.

How does this sound?

@Madis0 I am particularly interested in your opinion, as I see that you have forked this repository.

[Madis0]

Other than the latency, my primary motivation for forking was #58 - if we could all make the code reStyle-compatible, it would be easier for both developers and users to use this, like in the old Stylish days.

Here are my suggestions:

• Require userStyle-compatibility for every new PR and possibly revise old ones (Stylish compatibility #58, maybe some CI?)
• Some kind of CSS lint CI (not familiar with CIs yet, so can't be more specific)
• Consistent branches - either automate the versioning with Firefox's calendar somehow or get rid of the branches altogether and just mention in code comments what it has been tested with
• No need to test every piece of code IMO, CSS can't do very malicious things (that could not be reverted easily)

[Timvde]

Require userStyle-compatibility for every new PR and possibly revise old ones (#58, maybe some CI?)

Now I read that again, I see no reason not to add an @-moz-document to the styles. It seems better than the namespace I had in mind earlier.

Some kind of CSS lint CI (not familiar with CIs yet, so can't be more specific)

The thing is: me neither. I looked into this shortly, but I couldn't easily figure it out. That's why I proposed to do no checking at all.

Consistent branches - either automate the versioning with Firefox's calendar somehow or get rid of the branches altogether and just mention in code comments what it has been tested with

That's not really a lot for work actually. The problem there is that I postponed branching until after I merged in some PRs, but then never got to merging them...

No need to test every piece of code IMO, CSS can't do very malicious things (that could not be reverted easily)

Yes, it wasn't because of security, but correctness on all platforms. People usually only test on their own platform, but Firefox is different on all OSes, e.g. window buttons on the left in MacOS, no tabs in title bar on most Linux DEs...

[Madis0]

I looked into this shortly, but I couldn't easily figure it out.

Quick search now found me this.
https://github.com/marketplace/codefactor/

That's not really a lot for work actually

So you are willing to adjust all branches on every Firefox major update?

correctness on all platforms.

I guess that could be solved by issues:

1. Person 1 uploads a style for specific system/version
2. Person 2 comes and claims it doesn't work well for them
3. Person 3 with a similar system helps test and fix that

Asking uploaders to just test them on everything is going to slow/demotivate things down, especially because Firefox changes its CSS very often nowadays.

[Timvde]

I made a PR that adds all @-moz-document blocks. I have no idea if I should apply them to the style in the extension folder too. I copied the block from your quote in #58, but now I look at it, I actually think I should add quotes around the chrome:// url...

So you are willing to adjust all branches on every Firefox major update?

I won't maintain older branches, just fork once after every move from Nightly to beta

I guess that could be solved by issues

Agreed, that was the plan.

Asking uploaders to just test them on everything is going to slow/demotivate things down, especially because Firefox changes its CSS very often nowadays.

Yes, that's exactly what I noticed too, which is why I want to loosen it up.

[Madis0]

I'll review your PR soon.

So how are the branches going to work for contributors? You should clarify that in contributing.md to make everyone push to the right one.

Also, you might want to create an issue template too.

[Timvde]

So how are the branches going to work for contributors? You should clarify that in contributing.md to make everyone push to the right one.

The PR should usually be to master. I won't merge new features in other branches, although I'd take a PR for beta or release (not for unsupported versions) if they fix a bug.

Also, you might want to create an issue template too.

What should be in it?

[Madis0]

What should be in it?

Assuming the issue is about a style, otherwise the template can be ignored by the user.

• Style in question (file name)
• Bug or feature request (possibly in title too?)
• OS platform
• Firefox version
• Problem/request description

https://help.github.com/articles/about-issue-and-pull-request-templates/