On Thu, Apr 07, 2022 at 09:16:44AM +0200, Christian Couder wrote: > > > That said, if we do end up splitting the bitmaps GSoC project in two, > > > when would we need to do it by? > > > > To the best of my knowledge, Google does not require the proposal ideas to > > be laid out by organization before the proposal deadline (which is April 19). > > This gives the flexibility for mentors and GSoC contributors to collaborate > > and come up with a project ideas that are not present in the initial ideas > > list and write proposals for them. > > I agree with this, but please keep in mind that in > https://git.github.io/General-Application-Information/ we ask > applicants to "Discuss their project by posting drafts of their > application on the mailing-list long before the deadline." So > splitting the bitmap project should be done soon, so that applicants > have time to prepare and discuss their proposals based on the splitted > project. I've thought a little bit more about this, and I think we should leave the project in one piece (i.e., avoid splitting it up). My thinking is roughly that of the sub-projects listed: - investigate replacing EWAH with Roaring+Run - add a "table of contents" to the .bitmap file - append-only bitmap generation - amorphous / larger related projects ...the first two both require serious (re-)consideration of the .bitmap format, and I don't think it's possible to split that up among multiple GSoC projects. The "append-only" project is interesting, but probably not large enough for a GSoC student to occupy their time with completely. I think the last bullet point has the opposite problem, which is that there is _too_ much to do there, and that it isn't well defined enough. So we _could_ split the two projects up, having one work on any preliminary format changes, and the other stay busy with a smaller bitmap project, but I have significant concerns about that setup being successful. Instead, let's keep the project as-is, and have the accepted student focus on one of the first two bullet points, taking into account that we'll first want to spend some time thinking about whether or not the current .bitmap format is appropriate given the proposed changes. Thanks, Taylor
