Hi On Sat, Sep 30, 2023, at 00:52, Ralph Goers wrote: > Requiring hoops that must be jumped through before stuff can be > accepted is just a terrible idea. It does nothing but create a > perception that we are not open to new contributions and new > contributors.
I am also against hoops, but all for letting the users know how maintained (or not) a component is. We can accept everything, but first it goes too sandbox. It is the only sand thing to do. Because we didn’t do this, we had log4shell. We accepted a feature long time ago that nobody ever really used and forgot about it. We should at least tell the user what is maintained and what not. Sandbox, dormant and stable are not hoops but communication about the health of a component. > In short, I am in favor of retiring things when they are no longer > maintainable. This is very hard. As you know, I look into chainsaw right now. I believe it is currently not in a good state. It’s hard to read, technology is outdated (swing). Before I started, I would have said it is no longer maintainable. Now I still think the same, but with a lot of effort it could become maintainable again. Even log4j1 could be maintainable with a lot of people power. Following this, nothing would be ever retired. The better metric is: do we have the time to maintain it. If nobody is around who feels responsible a component could go to dormant indicating the state. > I am completely in favor of adding new components when > they make sense. IOW, every contribution needs to be considered on its > own merits. Agreed. Sandbox could be open even for all ASF committers, entry barriers could be low. Dormant components could go back to sandbox as well, if new people want to work on it. Christian > > Ralph > > > >> On Sep 29, 2023, at 11:32 AM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >> I think Jira is good enough for that, since there is transition from state >> to state that can be used to shepherd issues through. RFC, JEP, all way too >> heavy handed for us IMO. >> >> Gary >> >> >> On Fri, Sep 29, 2023, 2:05 PM Matt Sicker <m...@musigma.org> wrote: >> >>> I think it could be valuable for us to establish some form of an RFC >>> process for proposing and developing major new features. I also want to >>> avoid being too process-heavy here as that would also disincentivize >>> contributions. I agree that we should try to be more data-driven to >>> determine what features and products should have the most attention. >>> >>> I do like the idea of having “sample” plugins which are not distributed as >>> binaries, though, which can be used in documentation for examples of how to >>> integrate your own systems. With the flexibility of the plugin system here, >>> we can defer the implementation of more obscure integrations to the end >>> user. >>> >>> I will note that we do already have some level of filtering to what we >>> include. I’ve proposed numerous features in the past that I didn’t pursue >>> due to reasons raised by others or lack of interest. >>> >>>> On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>> >>>> I want to challenge the current way of PMC determining the product >>> feature >>>> set and work towards a more sustainable alternative. >>>> >>>> Logging Services team... >>>> >>>> - delivers mission-critical products that are deployed at the core of >>>> the world-wide infrastructure (actually, in Mars too) >>>> - is short on development resources compared to its wide range of >>>> offerings >>>> - deals with substantial amount of legacy >>>> - suffers from knowledge silo >>>> >>>> Any IT team in this state would be really conservative on accepting new >>>> features and try hard to get rid of the bloat. They would react to this >>>> challenge by first discovering the user base, pinpointing the core >>> values, >>>> and then lazer-focusing the limited development resources on to the >>> crucial >>>> deliverables. Though we do something totally different, one can even say >>>> the opposite. Below I share excerpts from recent mailing list posts. >>>> >>>> *"I had added [X] ... to show how to write plugins and for some >>>> consulting-related use cases"* – PMC member explaining how feature X was >>>> released >>>> >>>> *"... stuff seems like it could be useful"* – PMC member asking to keep >>>> feature X >>>> >>>> *"my employer used [X] ... for anyone implementing ... this would be very >>>> relevant. By archiving this we are basically telling users that they >>>> cannot use it any more since it will no longer be supported. For that >>>> reason I am not in favor of [retiring]"* – PMC member asking to keep >>>> feature X >>>> >>>> *"We [the employer] ... use [X]"* – PMC member asking to keep feature X >>>> >>>> *"User base [is] ... very low to non-existent."* – PMC member asking to >>>> keep product X >>>> >>>> *"[PMC member] has steadfastly [reacted] ... and until he positively says >>>> he will no longer maintain it I am not willing to override that"* – PMC >>>> member asking to keep product X because another (one and only) PMC member >>>> reacted on product retirement inquiry >>>> >>>> *"Our employers are ... paying customers."* – a PMC member explaining why >>>> we should keep feature X used by an organization employing another PMC >>>> member >>>> >>>> >>>> I see a pattern in the way we decide to maintain a feature/product: >>>> >>>> - It is not data-driven. It is disconnected from its user base. No >>> usage >>>> statistics, etc. is shared or used. >>>> - We serve individuals' and employers' agendas. >>>> - We underestimate the cost of adding/keeping a feature. >>>> >>>> I think this diet is "unhealthy" because: >>>> >>>> - It adds up to the bloat. It is yet another component developers need >>>> to maintain its dependencies, documentation, website, integration with >>> the >>>> build system, etc. This bizarrely slows down the development >>> experience. >>>> (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) >>>> - It adds up to the attack surface. >>>> - Features that are supposed to be optional get shipped to users >>> without >>>> their consent. (Consider the percentage of the Log4Shell victims that >>> used >>>> the JNDI functionality at all.) >>>> - Scarce development resources get wasted on chores due to the >>>> excessive landscape. >>>> - It gives users the wrong impression that the feature/product is >>>> maintained, though under the hood it is just kept there because a >>>> privileged group wants so. >>>> >>>> I want to refine this approach with your help. To start the discussion, I >>>> propose the following strategy instead: >>>> >>>> *"We only accept a feature with data-driven justification."* – Have a >>> brand >>>> new idea? Grab yourself a GitHub/GitLab repository that belongs to either >>>> you or your employer, knock yourself out without any ASF/PMC burdens, and >>>> amaze your users. Once the user attraction gets enough gravity, let's >>>> discuss blessing it as a part of the official Logging Services offering. >>>> Official support channels are always open to assist the developers of >>> such >>>> external efforts. >>>> >>>> *"We only keep a feature with data-driven justification."* – Do you >>> think a >>>> feature needs to be retired? Bring it up for discussion. PMC should >>>> evaluate the request based on numbers and this process should be >>>> independent of the individuals'/employers' agendas. If PMC decides to >>>> retire a feature/product *and* there are people who volunteer to continue >>>> the development on a successor fork outside of ASF, PMC should do their >>> due >>>> diligence to point existing users to this fork without any endorsement. >>>> >>>> >>>> I look forward to hearing your thoughts. >>> >>>
