Hi Tomek, Siddhi is interested in participating in GSoC, but the site design is not part of the GSoC.
I agree with you, the design he submitted is good, but needs more improvements. So, now that his initial PR is merged, let's see how the site will render. I saw you found some issues, but let more people take a look at it,probably we will receive more improvement suggestions. BR, Alan On Wed, Feb 18, 2026 at 5:09 PM Tomek CEDRO <[email protected]> wrote: > Hello Siddhi :-) > > Documentation contributions are always welcome. Just do not redesign > the whole thing. Small steps measurable results are the best, so > please start small, you will get familiar with the tools and process, > add missing parts for start :-) > > This does not sound like GSoC project but I may be wrong. > > Please note that the best work is done yourself with deep > understanding considering this documentation serves as reference point > for everyone else. Please only use AI tools when necessary for grammar > corrections only, so you can fully enjoy your own work results. > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Wed, Feb 18, 2026 at 7:48 PM Siddhi Tripathi > <[email protected]> wrote: > > > > Hello NuttX community, > > > > I'm a first-year B.Tech student who has been contributing to the > > nuttx-website > > repository (I have 3 merged PRs so far). I'm interested in working on > > improving the configuration documentation, potentially as part of GSoC > 2026. > > > > ## Why This Is Needed > > > > **1. Systemic Problem (Issue #16420):** > > > "There are many places in NuttX where configuration defaults are set in > > the > > > source code, not from Kconfig. This should be handled by Kconfig only > > > otherwise it can lead to hard to detect problems." > > > > This open issue, raised by @raiden00pl and confirmed by @acassis and > > @xiaoxiang781216, confirms that configuration fundamentally confuses > users > > because CONFIG_ macros appear in code that don't come from Kconfig. > > Link: https://github.com/apache/nuttx/issues/16420 > > > > **2. Additional Open Issues:** > > I've identified these related open issues: > > - Issue #12638: xtensa/esp32s3: Broken SPI configuration due to Kconfig > > changes > > Link: https://github.com/apache/nuttx/issues/12638 > > - Issue #12636: Build fails when disabling all filesystem support > > Link: https://github.com/apache/nuttx/issues/12636 > > - Issue #12629: arm64/qemu: Wrong configuration for Virtio console > > Link: https://github.com/apache/nuttx/issues/12629 > > > > **3. Real User Struggles:** > > - User having trouble with SPI configuration on ESP32-S3: > > https://lists.apache.org/thread/6oz6k7zfc7v4qx3dyt0o3ppf9n6rvzrw > > - Question about disabling filesystem features: > > https://lists.apache.org/thread/8roqonqo1b9lwob7p8o8k0f4k4l4k4l4 > > - Discussion about virtio console configuration: > > https://lists.apache.org/thread/9spqprq1c8v5qx3dyt0o3ppf9n6rvzsw > > > > **4. Fragmented Documentation:** > > Configuration information currently exists in README files but is not > fully > > migrated to the main website, making it harder for new users to find. > > > > ## Proposed Solution > > > > I'd like to create a comprehensive **NuttX Configuration Guide** on the > > main > > website covering: > > > > - Configuration fundamentals: Kconfig, .config, defconfig relationships > > - Working with "canned" configurations: ./tools/configure.sh usage > > - menuconfig deep dive: Navigation, search, hidden options (with > > screenshots) > > - Understanding CONFIG_ macros: Explaining the issue from #16420 > > - Common configuration tasks: Real examples from issues/threads > > - Troubleshooting guide: Based on actual user problems > > - Best practices: Avoiding hardcoded values, proper Kconfig organization > > > > ## Questions for the Community > > > > 1. Does this align with current documentation priorities? > > 2. Are there specific configuration topics you'd like prioritized? > > 3. Would this be better as a new "Configuration Guide" section or > > integrated > > into existing documentation? > > 4. Is there any existing work I should build on? > > > > ## Next Steps > > > > I plan to: > > - Gather feedback from this RFC (1 week) > > - Create a detailed GitHub issue with outline > > - Start drafting content section by section > > - Share progress for community review > > > > I'm happy to start with a small PR as a proof of concept and iterate > based > > on feedback. > > > > Thank you for your time and guidance! > > > > Best regards, > > Siddhi Tripathi > > GitHub: siddhitripathi25 >
