Indeed. Perhaps the solution is to increase the number of licensees that do have this knowledge or at least know where to go find it, so they can help these projects. When I get asked to help sponsor something from a new group, the first question I ask is: who from your group might be already versed in the lore, or might be willing to learn.
-- mark James Carlson wrote: > John Plocher writes: > >> In my book, a project team that utters that sequence of phrases is >> really telling the world that they need help, that they are not yet >> able to do the job being asked of them - which is to develop software >> for a world class operating system. We need to find better ways of >> working with them to help enable them to do better. >> > > It sounds to me like you might be expecting at least some teams > (perhaps "many") to be fully conversant in all of the Best Practices. > I'm not sure that's realistic. > > I expect to see that project teams understand their technical areas > very well. I also expect them to understand a fair amount about > adjacent areas. I don't necessarily expect them to understand > _everything_ about _everything_, particularly at a system level. > > That's where those (sometimes silly) enumerated questions from the ARC > come in handy. Project teams don't necessarily think about patching, > or README documentation, or contracts, or security requirements, or > clustering, or versioning, or a host of other things. In fact, I > expect that gap to be the norm, and addressing the gaps to be part of > what the ARC should do well. > > Sure, it'd be wonderful if everyone coming to ARC review was a > renaissance developer, but I doubt it works as a general goal. There > are just too many details for us to say "go read everything on this > web site and come back." > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20081017/f498d280/attachment.html>
