[19:06] <SteveAgl> the speacher is still away...
[19:06] <skippy> screw it. let's get started.
[19:07] <SteveAgl> the agenda #1 is:
[19:07] <SteveAgl> Committors: is bg|commit still useful? It seems nowadays that Matt/Ryan just work their way through open bugs and I can't seem to find much correlation between bugs I/we've tagged as bg|commit and actual ones committed. DavidHouse
[19:14] <skippy> well, since photomatt_away isn't here, and I don't see ryan, let's put that on hold.
[19:14] * Joins: mikelittle
[19:14] <skippy> and we need commiters to talk about the next item, too.
[19:14] * Joins: masq|lappy
[19:14] <skippy> so, moving on to item #3...
[19:14] * Joins: skeltoac
[19:14] <skippy> only photomatt_away can talk about the problems with the forums.
[19:15] <skippy> so, we're done. thanks for coming, everyone. productive meeting, as usual.
[19:15] * Joins: SteamedPenguin
[19:15] <skeltoac> Sorry I showed up late. Can I help with anything?
[19:15] <MichaelH> good job skippy ;)
[19:15] <skippy> is bg|commit a helpful tag, skeltoac ?
[19:15] <skippy> and do you review the list of user-flagged commit candidates?
[19:16] * Joins: rboren
[19:16] <skeltoac> I don't commit patches so I can't answer the first question. I pinged Ryan to jump in here so maybe he can...
[19:16] <skeltoac> there he is :)
[19:16] <skeltoac> rboren: is bg_commit useful?
[19:17] <rboren> Yes, I look at it when I go on commit runs.
[19:18] <skeltoac> skippy: as to your second question, I only review patches when someone asks for my opinion on them.
[19:19] <skippy> http://trac.wordpress.org/report/9 <-- is the grouping on that helpful? Or would a date-based list be more appropriate?
[19:20] <rboren> By date might be better.
[19:20] * Joins: ringmaster
[19:22] <skippy> updated the report. let me know if it's broken, or ineffective in any wya
[19:23] <SteveAgl> where are the trac tag documented?
[19:24] <skippy> i don't know that they are.
[19:24] <skippy> for a while, it was mostly MarkJ and I adding tags ourselves.
[19:24] <skippy> they're all pretty self-explanatory: bg|needs-patch, bg|has-patch, bg|2nd-opinion, bg|commit
[19:24] <skippy> the bg| prefix means "bug gardener"
[19:25] <SteveAgl> oh ok :)
[19:25] <skeltoac> bg|reporter-feedback but reporters rarely come back to check.
[19:25] <SteveAgl> was the bg part not understood by me :)
[19:25] <skippy> we could probably drop that, going forward.
[19:26] <skippy> then modify the reports to not use that in the query.
[19:27] <skippy> any objections to dropping the bg| prefix ?
[19:28] <skeltoac> Not so much.
[19:28] <skippy> so the "commit" tag is still useful. That's good to know
[19:29] <skippy> we need photomatt_away to address the Codex problem. Anyone have anything else to discuss?
[19:29] * Joins: davidhouse
[19:30] * Joins: shep
[19:30] <skippy> any feedback on inline documentation (PHPdoc) ?
[19:31] <shep> i'm here. we can start
[19:31] * Quits: gsnedders
[19:31] <davidhouse> skippy, i'd like to see it.
[19:31] <davidhouse> lets not go overboard.
[19:31] <davidhouse> one or two lines before every function is about righ.
[19:31] <SteveAgl> would be nice to have
[19:32] * Parts: ringmaster
[19:32] <skippy> okay. rboren: would you commit patches that contained nothing but comments?
[19:32] <shep> i have a quick question. a feature request that i thought was supposed to be addressed in 2.0
[19:32] <SteamedPenguin> davidhouse: there are benefits to PHPDoc, as in autogenerating the documentation periodically. makes it easier to export too
[19:32] <rboren> Depends on what they were commenting...
[19:33] <rboren> IF breaking down a tricky regex, probably.
[19:33] <davidhouse> SteamedPenguin: henec my support.
[19:33] <shep> is saving a page as a draft ever going to be included in WP?
[19:33] <skeltoac> shep: it's in.
[19:33] <SteamedPenguin> rboren: that's sounds like an 'if and only if'
[19:34] <shep> skeltoac: in 2.0.1?
[19:34] <rboren> Well, if the comment is a bunch of boilerplate, probably not.
[19:34] <davidhouse> shep, no, 2.1
[19:34] <rboren> But, it's a philosophical discussion.
[19:34] <davidhouse> my commenting policy:
[19:34] <davidhouse> one line summary before every function
[19:34] <davidhouse> comment when you do something voodoo
[19:34] <davidhouse> comment when you begin a big chunk of code (say a big loop)
[19:35] <SteamedPenguin> rboren: so something like var listing and var typing would not go in?
[19:35] <davidhouse> that's it.
[19:35] <skippy> I was once encouraged (elsewhere) to only comment the extraordinary and non-obvious; but that sets an ambiguous standard. Obvious to the person who wrote it is often non-obvious to the newbie
[19:36] <rboren> SteamedPenguin: I wouldn't right now, but we can discuss on the hackers list and see where people fall.
[19:37] <skeltoac> The major argument I see opposed to extensive commenting is that it takes time to review them.
[19:38] <SteamedPenguin> skeltoac: a fair ammount of function description can come straight out of the codex.
[19:38] <SteamedPenguin> at least where template tags are concerned
[19:40] <SteamedPenguin> skeltoac: since that stuff has the most eyeballs it ought to be the first target for inline commenting as well as the easiest to accomplish
[19:40] <SteamedPenguin> making template tags a good test case, IMO
[19:42] <skeltoac> You can always upload patches and ask for peer review. If you have a good set of comments and they've been okayed by a number of devs, Ryan doesn't have to spend his day reading them over.
[19:42] <skeltoac> (I hope, anyway.)
[19:44] <SteamedPenguin> skeltoac: ok, I'll make a simple patch tomorrow then.
[19:45] * Quits: SteveAgl (Read error: 104 (Connection reset by peer)�)
[19:45] * Parts: shep
[19:46] * Parts: skippy ("Free as in Puppies!"�)
[19:47] <mumbles> shoudlent that be </endmeetup>
[19:48] <PotterSys> </meetup> ?