On Thu, Jan 30, 2025 at 8:32 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Thu, Jan 30, 2025 at 11:14:06AM +0530, Kaartic Sivaraam wrote: > > We could certainly curate it from time to time. I wonder how > > we could set the timeline for a microproject idea, though. Would it make > > sense to fix a rough timeline such as 1 year or so and remove any idea > > whose age is more than the same? > > That'd be fine with me. Ideas don't necessarily have to get removed > immediately, but may get "refreshed" in case they are still accurate. > So personally I'd frame it less like an expiration date and more like > the following: > > Every topic added to the list will need to be checked regularly for > whether it is still accurate so that we can avoid an ever-growing > list of stale topics. As such, every topic needs to be accompanied > by a "best-before" date that indicates when the next check for this > topic is due. > > It is the responsibility of the owner of the topic to determine > whether it is still accurate. This check should happen close to the > noted best-before date and come in the form of a patch that either > bumps the date in case it _is_ accurate, or alternatively removes > the topic from the list in case it is _not_ accurate anymore. > > In case the topic owner does not send such a patch, contributors > other than the owner are encouraged to send a patch that removes the > topic, putting the owner into Cc. Thanks for this. I will use something similar. > Well... maybe it _is_ an expiration date. I dunno, I don't mind which > exact term we use for it. I don't mind much either. > In any case, my proposal would be to add this paragraph or a variant > thereof to a preamble explaining the purpose of the document as well as > how to use it. This is somewhat similar to how our "BreakingChanges.txt" > lays out expectations, which I think should be an inspiration for the > new document, as well. Sure. > > Also, the current list of ideas could roughly be seen here: > > > > > > https://github.com/git/git.github.io/blob/2025-microprojects/SoC-2025-Microprojects.md#ideas-for-microprojects > > > > The topics are: > > > > - Fix Sign Comparison Warnings in Git's Codebase > > > > - Modernize Test Path Checking in Git's Test Suite > > > > - Add more builtin patterns for userdiff > > This one doesn't feel like a sensible addition to me as it is > open-ended. > > > - Replace a run_command*() call by direct calls to C functions > > This one, too. We could put those two in a section for projects that are a bit larger than microprojects though. It might help those who have already worked on a microproject and want to do something a bit more involved. It happens more and more often that people who want to apply to the GSoC or Outreachy start getting involved early, which is nice. They often have time, after their microproject and before working on their application, to work on something a bit more involved. So it would be nice if they could easily find something else to work on like those two ideas and others similar to them. > > - Avoid suppressing git's exit code in test scripts > > > > - Use unsigned integral type for collection of bits. > > > > - Modernize a test script > > > > Do share your thoughts on which of these you find being relevant > > currently. That would help in preparing the first version of the in-tree > > project ideas list. > > All the other topics are ongoing topics indeed and would be a good fit > from my perspective. I agree. > Note that Chris is also preparing such a doc right now, so you might > want to coordinate with him. Yeah, I need to prepare a draft for the next Git Rev News edition first, but I will work on this really soon after. Thanks.
