Is there a need for a centralized repo for "Explorations"?

[fg-j]

@thitch97 and I have started exploring what it will mean to implement the BP_LIVE_RELOAD_ENABLED feature described in the Reloadable Process Types RFC. To do so, we are investigating things like watchexec and Tilt, and writing summaries of our findings.

We created a new repo in the Paketo buildpacks org to hold artifacts created in our exploration and issues we've filed to track the exploration work. We thought it was important to check these things into an open source repo as a transparent decision record for the community.

However, Paketo doesn't have governance dictating what should happen with a repo like this. Does it have maintainers? Who's allowed to create a repo like this? Can any maintainer fire up an exploration-oriented repo whenever they choose?

Moreover, I suspect this is not the only exploration that Paketo contributors have done in service of future Paketo buildpacks development. But it's not clear to me where (if anywhere) these explorations are publicly visible.

This leaves me wondering: Would Paketo benefit from a repo where exploration work can be tracked via issues and preserved for posterity as checked-in artifacts?

A couple of benefits, in my mind:

• There is a centralized place for the community to look for completed and ongoing investigations
• Avoids proliferation of new exploration repos that are actively used for short periods of time

What do others think? What would you check into an "explorations" repo if it existed? What risks come up if we create a repo like this?

[sophiewigmore]

@fg-j I would support an explorations repository in Paketo Community, rather than Paketo Buildpacks.

I have encountered this issue when working on bill of materials work, and resorted to creating a personal explorations repo. I know I have seen other folks on the core development do the same before.

It would help with discoverability if all of our explorations were in a dedicated place, and I would definitely be inclined to PR my previous explorations in. If the explorations were public-facing in a Paketo repo, it would also (hopefully) encourage people to write up READMEs for their explorations to make the takeaways more digestible.

[sophiewigmore]

Would we need an RFC to propose the creation of such a repository? My only other concern is communicating this repository's existence, so that people are aware of it and actually contribute their explorations.

[dmikusa]

+1 for an RFC - I think there's more to it than just creating a repo. We could spell out some governance for the repo.

I think the RFC could also propose something be added to https://github.com/paketo-buildpacks/community to promote usage & sharing through this forum. It seems like a community-building activity to me. My $0.02.

[dmikusa]

I have created personal repos as well as WIP branches to do work like this. I think making this type of work easier to share would be nice.

My concerns:

• What is the useful lifetime for material like this? I tend to use them for short spikes & prototypes. Things that don't stand the test of time. It makes me think a clean-up policy would be necessary.
• I worry about the repo being a dumping ground, and about how easy it would be for someone to make any sense of the repo. I wonder how we can enforce some standard of quality for what is published there. Specifically having sufficient documentation and notes so someone can reasonably follow along with the work contained there. Perhaps having some requirement for a person publishing there to be accessible in some way to field questions, perhaps through Slack?

[fg-j]

I've written up a little RFC about this: paketo-buildpacks/rfcs#119 @dmikusa-pivotal @sophiewigmore would love to hear your thoughts about the proposal. I've tried to take your feedback on this thread into consideration.