Hacktoberfest / good-first-issue
by Brian Stansberry
October is almost here, which means it's time for Hacktoberfest! WildFly
is again participating, and a key part of that participation is identifying
a suggested list of issues that might be appropriate for someone to take
on. These are ones that outside of October we'd label as 'good-first-issue'.
If you have a moment, please have a look at any WFLY JIRAs in your area of
responsibility and if they seem like candidates, please apply the
'good-first-issue' label. There's also a 'Estimated difficulty' JIRA field
that we don't use much, but I think it's good to set it for these. Some
good first issues can be fairly challenging, which is ok, but if that's the
case the issue should note that.
It's also good to have a look at any good first issue from the POV of
someone new and see if the title or description can be improved.
https://issues.redhat.com/issues/?filter=12421535 shows the current list of
labeled issues for WFLY.
Note that I'm only talking about WFLY here, but I know other WildFly
related projects are also participating. I just didn't want to ask people
to start doing things with other JIRA projects without prior discussion
with the project leads.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 months, 1 week
Rename 'default' stability level
by Brian Stansberry
One of the bigger pain points I'm seeing with our stability level stuff is
the name/meaning of the 'default' level. The only sense in which that one
is truly 'default' is the internal implementation detail that in various
management kernel classes it's the default value of some fields. Which is
irrelevant to anyone but developers of WF. It's not the OOTB, aka 'default'
stability level of standard WildFly or of WildFly Preview.
This has been a recurring topic of discussion, and I think early in the WF
35 cycle would be a good time to fix it.
If we change it we should make sure the old value still works (as an alias)
in places where users can set it.
Darran suggested using 'base' instead, which I personally like.
The true meaning of this level is "same as community, but we made sure
people with formal QE and docs writing expertise were part of the feature
team". In lots of conversations about alternative names no one came up with
a good word that has that meaning. Surprising! 'Endorsed' came closest.
Adjacent concepts like 'mature' came up but that implies age, and things at
this level are not necessarily older. Plus the opposite is 'immature' and
that's not the intent of 'community'.
I like 'base' because it sidesteps the above and focuses on the fact that
our levels are basically supersets of each other in terms of what sets of
features are available. And what's available in 'default' stability is the
core, or 'base' set.
Thoughts?
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
2 months, 1 week
