*My* particular issue around this was not knowing what to do with configuration parameters and APIs.
If we simply remove those, older clients, older configs would not work any longer. Is deprecation here a valid approach? Is there consensus around it ? On Thu, Nov 5, 2020 at 11:15 AM Rich Bowen <[email protected]> wrote: > Hi, ActiveMQ friends, > > As you may have heard, Red Hat recently embarked on a company-wide effort > to remove problematic/unwelcoming language from code, documentation, and > web presences, both upstream and downstream, related to projects that we > care about, and which form critical parts of our technology stack. Camel > is, of course, one of those projects. > > We are joined in this effort by colleagues at a large and growing number > of technology companies and organizations. > > Our CTO Chris Wright blogged about this - > https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language > - back in June and we have been making steady - if slow - progress since > then. > > I'm in the process of reaching out to various projects to see what we can > do to get this work done. > > I was wondering if ActiveMQ is looking at this issue at all. > > A lazy github search shows, of the words that we've been focusing on: > > Slave > https://github.com/apache/activemq/search?q=slave > 77 > > Master > https://github.com/apache/activemq/search?q=master > 121 > > Whitelist > https://github.com/apache/activemq/search?q=whitelist > 1 > > Blacklist > https://github.com/apache/activemq/search?q=blacklist > 1 > > We've drafted a document about how one might approach this topic - > https://github.com/conscious-lang/conscious-lang-docs/blob/main/recommendations.md > and a faq at > https://github.com/conscious-lang/conscious-lang-docs/blob/main/faq.md if > you'd like to read more about the "what", "why", and "how" of this project, > and I'd be glad to discuss this more with any of you. > -- Clebert Suconic
