Inconsistent punctuation in function group descriptions

[athowes]

Inconsistent punctuation in function group descriptions

[pearsonca]

Seems minor.

If we did want to do this: where does the styling guidance go? Is there a static analysis / CI enforcement mechanism?

My thinking is basically that assessing the worth of these kind of changes is balancing their value (and I agree that there is some positive value to consistency here) against the cost of obtaining and maintaining that value (style guide update seems like a cheap fix, but unlikely to actually keep things in line; YAML linting CI seems expensive for just this, but perhaps there are other benefits to having that running?)

[athowes]

Fair enough: agree very minor and quite possibly a waste of time. I'm used to working on my own so still getting calibrated on scale of issues worth raising / fixing in collaborative context! Happy to close.

[seabbs]

So it not being a priority for @pearsonca or me is not a reason to close as its still a issue and so we should have it for visibility if nothing else.

I think this is a great issue for a new contributor and it also suggests a new issue for the contributing guide and potentially the CI that @pearsonca is talking about (although agree that is quite a lot of engineering for minimal gain).

The key here I think is maintaining these kinds of standards can be top down or it can bee the case that you set a standard and then leave users/community to help you get coverage (which is what I think we should do here)

I've tagged this as help wanted and won't fix (i.e core devs probably won't do). @athowes if you are feeling like making a quick contribution this would be a much appreciated standardisation (also I enjoyed the open/close tag)

[pearsonca]

So it not being a priority for @pearsonca or me is not a reason to close as its still a issue and so we should have it for visibility if nothing else.

I think this is a great issue for a new contributor and it also suggests a new issue for the contributing guide and potentially the CI that @pearsonca is talking about (although agree that is quite a lot of engineering for minimal gain).

The key here I think is maintaining these kinds of standards can be top down or it can bee the case that you set a standard and then leave users/community to help you get coverage (which is what I think we should do here)

Good catch on other pro here: introductory work for people that are just starting with this package / open source contributions in general (though the CI update is definitely not light work).