-
Notifications
You must be signed in to change notification settings - Fork 1.8k
docs: Update documentation on Epics and Supervising Maintainers #17505
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
Conversation
| maintainers are more likely to sponsor features they are particularly interested | ||
| in or align with their use of DataFusion. | ||
|
|
||
| If you are willing to be a sponsoring maintainer for a feature, please say so |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alamb please help me to understand Sponsoring Maintainters. Are you suggesting to create a pool of active maintainers for specific feature, like XYZ, ABC is supporting Join development, QWE for planning, ZXC for optimizer work?
So the PR author can tag all of them and depending on availability the maintainers can help review.
Is my understanding correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to make it clear that any project that doesn't have an active maintainer that is willing to help move it along to completion is unlikely to succeed. Maybe this is obvious but I think it might help to make it explicit.
I don't think we have a formal process (yet) to find such a maintainer other than the normal course of comments, etc. Clearly I play this role for many of the projects, but I am hoping to move to a place where other committers can also drive move projects too.
Hopefully that makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try and reword this a bit for clarity too
|
LGTM |
comphead
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @alamb it is a great start
2010YOUY01
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the great explanations 👍🏼
|
|
||
| We have found that most successful epics have one or more "sponsoring | ||
| maintainers", a committer ([see here for current list]) who take the lead on reviewing and committing PRs, help with design, | ||
| and coordinate and communicate with the community. Without a sponsoring |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can explicitly say: If you want to ship a large feature, we recommend finding a sponsoring maintainer upfront; otherwise, the PRs might remain unreviewed for a very long time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great idea -- I added this in 075ebde
Jefffrey
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth changing the term "sponsoring" to something like "driving" or "championing", to avoid any confusion with the monetary meaning of sponsoring?
That is a really good point. Here are some brainstorm options
🤔 |
|
Of the options given here I feel that "driving" and "championing" might lean a bit too colloquial and might be more difficult for non-native English speakers in the community to understand (caveat: I am a native English speaker, so I may be entirely off base here as I have absolutely no personal reference). I believe that "supervising" or "managing" is likely the most clear. I think other options in this vein would be "lead committer" or "principal committer".
I think this is perhaps a bit less clear than some other options, but like how it implies a more collaborative relationship between the community member and the committer. Another potential option for a more collaborative word might be "mentoring committer". |
| the role, as it can be hard to tell sometimes whether a committer is simply | ||
| participating and giving general feedback. | ||
|
|
||
| [see here for current list]: governance.md |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be reasonable to directly link to the "phone book" here (https://projects.apache.org/committee.html?datafusion) instead of the governance doc? I'm personally not very familiar with these docs and skipped right over the "phone book" link on the governance doc when I first looked at it because I was looking for a list of usernames of committers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and this is a good point about the phone book in general -- I'll try and make that easier to understand
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made a separate PR to do this
|
I'll add my vote for "Supervising Committer" |
+1 for supervising. I agree |
|
Perhaps we can add it to the issue template: |
I think this is likely a good idea. However, I suggest we wait to see how much this idea of supervising maintainers works out and then add it to the template if it seems it is gaining traction |
|
I'll plan to merge this tomorrow unless anyone has additional comments |
|
All right -- I put it in the merge queue and hopefully it will merge shortly |
|
Whoo hoo the merge bot is working ! |
Which issue does this PR close?
Rationale for this change
It can be unclear
What changes are included in this PR?
Here is a rendered preview:

(updated)
Are these changes tested?
by ci
Are there any user-facing changes?
yes, new docs