As a mentor, I would recommend you avoid any concept of “ownership” like the plague. It implies a project hierarchy that ASF projects do not have.
In ASF projects committer bits are boolean. Bob’s committer bit is no different from Alice’s. Their project expertise may lie in different areas of the codebase, but they are inherently *trusted* not to make reckless changes without collaboration/review with other committers. If you feel you must go down this path, I would suggest different language than “owner”. At best it should be an informal designation (not a role) by a volunteer who is willing to help shepherd that section of the codebase (e.g. help with/perform PR reviews, groom issues, revive discussions, etc.). I would also recommend documenting the concept, specifically how others can get involved. -Taylor > On Apr 5, 2018, at 6:02 PM, Karthik Ramasamy <[email protected]> wrote: > > Ashvin - > > It could be good to designate owners for different areas - let me come up > with a list by the end of the today tonight. > > cheers > /karthik > > > On Thu, Apr 5, 2018 at 11:42 AM, Ning Wang <[email protected]> wrote: > >> Make sense to me. >> >> >> >> On Thu, Apr 5, 2018 at 9:19 AM, Ashvin A <[email protected]> wrote: >> >>> Hi Devs, >>> >>> PR 2840 renames com.twitter package to org.apache. This change touches >> more >>> than *2,127* files. Is there a test strategy for this change which >> updates >>> everything? I believe just depending on unit and integration tests may be >>> insufficient. >>> >>> Also I am hoping git history will be preserved. >>> >>> Should we create a coarse checklist and take ownership of manual >>> verification of individual components? >>> >>> 1. Examples >>> 2. Heron UI >>> 1. Metrics >>> 2. Logs >>> 3. API server >>> 4. Heron client >>> 5. Docker >>> 6. Schedulers >>> 1. Aurora >>> 2. Kubernetes >>> 3. Yarn >>> 4. .. >>> 7. Python >>> 8. Heron Tracker >>> 9. Heron metrics cache >>> 10. Heron Health manager >>> 11. ... >>> >>> >>> Thanks, >>> Ashvin >>> >>
