<div dir="ltr">Thanks, that seems to be what I was looking for.<div><br></div><div>It is, however, kind of coarse. Maybe you should consider updating it and expanding it to a more fine-grained listing. I also think that this list could be publicized a bit more, so that one can actually find it more easily through the LLVM/Clang web-site and via google searches.</div><div><br></div><div>It didn't occur to me, right away, to inspect revision histories for some files as a way to get the few relevant names for a specific part of llvm/clang. It seems that I had already tagged the right person for my patch (Sema / template instantiations, which seems to be Richard Smith's responsibility (?) as I had guessed from his name coming up often on those related topics on the mailing list).</div><div><br></div><div>Even though you could say "you should have thought about checking code_owners and/or revision histories", my humble feedback as an outsider is that I didn't think of that or know that, indicating that there might be a need for a more publicized / obvious way of getting to that information. Simply mirroring the code-owners lists on the public webpage (and linking to it from submission instructions) would be great (on second examination, it seems that LLVM's webpage link to it, but not the Clang "getting involved" instructions).</div><div><br></div><div>Finally, isn't the concept of "code owners" (from LLVM's docs) a bit fuzzy? Not really maintainers, not really reviewers, not really responsibility-baring, not really vetted / elected / performance-reviewed, etc... I would suggest that this might be formalized a bit more, in terms of responsibilities and expectations. Also, how would you detect that a part of llvm or clang is being under-maintained? Or that a particular maintainer is being over-whelmed by what he/she is responsible for? Except anecdotally or by complaints. For example, if a particular maintainer is consistently drowned in pending patch reviews, then that should and could be detected. There could also be more formalized dead-lines and stuff to make sure patches don't just drop off into the ether, or require constant bumping or re-submitting of them to pester the maintainers until they budge.</div><div><br></div><div>> <span style="color:rgb(0,0,0);font-family:Helvetica,Arial;font-size:13px">you can just write questions to the mailing list and a person, who takes responsibility and/or has a good domain knowledge, might pick your question/patch and provide some help or advice.</span></div><div><span style="color:rgb(0,0,0);font-family:Helvetica,Arial;font-size:13px"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Helvetica,Arial;font-size:13px">That's a very hit-and-miss process. Lots of stuff just drops off into the ether. Even the phabricator system is very hit-and-miss, from what I'm seeing.</span></div><div><br></div><div>> <span style="font-size:13px">If you have specific concrete suggestions on how to reduce this impression, please list them.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">I don't really have too many concrete suggestions. I'm really just providing my feedback or impressions as an uninitiated contributor. In coder-speak, just treat this as a "bug report" that I'm giving about this issue, and I don't really have a patch for it, but I'll think about it, and I hope you guys will too.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Cheers,</span></div><div><span style="font-size:13px">Mikael.</span></div><div><div class="gmail_extra"><div class="gmail_signature"><br></div>
</div></div></div>