Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify expectations about external contributions #753

Open
cbarrete opened this issue Aug 25, 2024 · 0 comments
Open

Clarify expectations about external contributions #753

cbarrete opened this issue Aug 25, 2024 · 0 comments

Comments

@cbarrete
Copy link
Contributor

First things first: it goes without saying that open source users are not entitled to Meta employees' time or attention. I appreciate the time and effort that the Buck2 team invest in making Buck2 open source, usable by open source users, as well as all the time that they spend engaging with the community, both in official and unofficial channels.

With that being said, it is unclear to me what expectations open source users should have when it comes to contributing to Buck2, both in the form of issues and PRs. From the outside, it is difficult to understand what might constitute a welcome contribution, and what will cause it to be engaged with by the Buck2 team. When a contribution receives no feedback, it is difficult to determine whether it is not welcome, if so why (low quality? not aligned with the team's vision or priorities? a PR was submitted without prior conversation in an issue?), and if not how to get it unstuck (has it just been missed? has the owner been away? should the contributor ping someone? if so, who and after how long?).

On a personal note, I often find that I do not know whether it is appropriate to tag someone in an issue or PR, and if so, who should be tagged. I do not want to come off as pushy or to abuse the team's time and attention, so it would be very helpful to know what the team's expectations are here.

On a professional note, it can be challenging to plan around changes being merged upstream when there are no rough estimation of whether or when that will happen. Again, I have no expectations that the team should engage on such changes, but even a guideline like "don't expect a change to be discussed or merged if you don't hear back from us within a month" would be much more useful and actionable than nothing at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant