Personally, I'm not against nagging. Actually, when I'm on the receiving end, I usually appreciate it, as timeliness is not a quality I am widely praised for.
Some podlings are in a position that is different from TLPs - they are new to the whole thing, and may therefore require a little more help than we would expect a TLP to need in remembering their responsibilities. However, if I were needing to nag a podling that is otherwise near graduation, I'd perhaps be worried. The DNR marker is still important though, and we should be sure that we don't 'over-nag'. We encourage (more earlier in the process of incubation, less later) and if after a few nags they don't do it, then DNR is just fine. Upayavira On Tue, Dec 18, 2012, at 09:04 AM, David Crossley wrote: > Tim Williams wrote: > > On Mon, Dec 17, 2012 at 7:48 PM, Benson Margulies <bimargul...@gmail.com> > > wrote: > > > On Mon, Dec 17, 2012 at 7:35 PM, Marvin Humphrey <mar...@rectangular.com> > > > wrote: > > >> On Mon, Dec 17, 2012 at 4:04 PM, Tim Williams <william...@gmail.com> > > >> wrote: > > >>> FWIW, I feel the same. I'd rather see 'did not report' and let the > > >>> IPMC look for that pattern. Maybe just have your template generator > > >>> default to DNR in the text? > > >> > > >> +1 on defaulting to DNR. > > >> > > >> How about sending out the whole Incubator report to all podling dev > > >> lists, > > >> every month? That way the DNR shows up without an IPMC member having to > > >> notice and take action. But in addition, it increases podling exposure > > >> to > > >> other projects and to the ASF at large. > > >> > > >> An alternative is to send it out to only the podlings that are reporting > > >> for a > > >> cycle, but that's more work and doesn't serve the purpose of connecting > > >> the > > >> podling to being in the Incubator quite so cleanly. > > > > > > > > > I feel all that we are all volunteers, that podlings are volunteers > > > who don't necessarily have their organizational act together, and that > > > calling them out for DNR is not a very effective technique to > > > providing the supervision that we, as a PMC, are on the hook for. So > > > I'm inclined for now to nag, and to spend a few minutes making that > > > job less labor-intensive. > > > > I'm beginning to think your mind's made up and the original question > > was a pleasantry, but in case not... > > > > I hold a different view of things. While I think that we, ok you, are > > on the hook for a board report, we've (PMC) delegated[1] the reporting > > of each podling to the mentors that we approved for that podling. We > > aren't "calling out the podling" as DNR - we're calling out their > > mentor as DNR. If there's additional nags to go out, I'd do my > > "default to DNR" and send the nag to the mentors directly. > > > > Ultimately, making that job less labor-intensive involves getting > > mentors and would-be-mentors to realize they can't simply go around > > spewing their seeds as absentee fathers - it's a real commitment; to > > the podling and to the foundation. Shucks, keeping a record of > > deadbeat mentors would prolly help... > > > > In the end though, you've a thankless and tough job, so consider these > > as constructive thoughts to be readily ignored in favor of whatever it > > takes to get your job done:) > > > > Thanks, > > --tim > > > > [1] - > > http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor > > Things should be in their hands as much as possible. > > In my opinion each podling group of developers should be > ensuring that their board report is ready, with the mentors > just mentoring and making sure that actual status does get > reported. > > I wonder if we could utilise the podling metadata system > at content/podlings.xml > to get a podling PPMC member or a mentor to set an attribute > to mark that the report is received. Put the PPMC in the loop. > > This gets them used to overseeing their own project, being > self-reliant, and maintaining their own records. > > Another benefit of editing that file is that they see when > their next report is due and whether their metadata needs > to be updated. > > Any nag to them could encourage them to visit that file. > > -David > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
