Kirk, 1) I would check out the project management features built into GitHub, e.g., labels, milestones, and projects https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects .
2) Ultimately, the contributions will need to follow the normal PR workflow. A committer will have to review and approve the changes. For big changes, it's probably best to get more than one committer to approve. Do you expect the changes to come in incrementally, or as a few large patches? For major efforts in the past, we have taken the approach of using a non-trunk feature branch where we land and stabilize new code. The downside here is the effort involved in integrating new changes from upstream. If it's mostly greenfield work (i.e., new classes), this might not be a big problem. Another downside of this approach is the effort involved in reviewing a massive PR to trunk that is bringing in a large code base. Here's a possible workflow: * Create a feature branch on a fork * Non-committers can commit directly to this branch, or use a PR workflow using the feature branch as a base * Stabilize the feature branch * Break the changeset into a few sensible PRs for merging into trunk. This could be something like interfaces and configs first followed by implementation and tests. To answer this more directly > Is there a recommended path to collaborate for non-committers? The normal collaboration path for non-committers is to submit Pull Requests against trunk. Non-committers can review PRs, they just can't merge them or +1 them. HTH, David On Thu, Apr 27, 2023 at 8:15 PM Kirk True <k...@kirktrue.pro> wrote: > Hi all, > > A handful of engineers are collaborating on a fairly sizable project to > improve the Java consumer client [1]. We are using as many ASF tools as > possible for the work (wiki, Jira, mailing list, and Slack thus far). > > There are yet two areas where we need recommendations: > > 1. Project management tools. What is the recommended tool for > communicating project scheduling, milestones, etc.? > > 2. Shared code collaboration. Since none of the engineers on the project > are committers, we can't collaborate by reviewing and merging our changes > into trunk. Is there a recommended path to collaborate for non-committers? > > Thanks, > Kirk > > [1] > https://cwiki.apache.org/confluence/display/KAFKA/Consumer+threading+refactor+project+overview -- -David
