I wasn't implying a formal paper work people need to follow. I just wanted to establish a consensus on the discussions of which features to keep/drop should be driven by data.
On Fri, Sep 29, 2023 at 8: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. > >
