WordPress Dev Chat For 7-15-09

From now on, the way I am going to format these posts is to bold the item that was listed on the agenda and then below it, publish a summary of what was decided for that item.

Creating an announcements mailing list that include all plugin and theme developers and using it to send information on significant core changes that are likely to affect them. It would be very low volume (1-2 emails per month) and would include by default everybody that is listed as contributor to at least one plugin or theme hosted on wordpress.org. Of course it would be open to everybody to subscribe or unsubscribe.

The majority of folks who participated in the chat agreed that this was a great idea. The list would be low volume where announcements could be pushed out if their are changes to the WordPress API. This would provide theme and plugin authors a heads up on a change that may break their project. Plugin and theme authors would have the ability to ‘Opt-Out‘ if they don’t want the announcements.

matt posted about adopting plugins: “I saw something on PEAR today I like (I know, gasp!) and it was where certain modules were marked as abandoned and up for adoption, and they seemed to have a mechanism for adoption.” example: http://pear.php.net/package/Net_DNS

Many thought the idea of inactive plugins on the repository to be put up for adoption was a great idea. If an author got an email about a change and knew they weren’t going to have time to bother updating, the WordPress team could point them somewhere to announce that. The thinking right now is that based on a number of failed attempts to get in touch with the plugin author could be a base for what is considered non maintained. Then it goes up for adoption, or branches and the old one is marked as dead.

scribu – an edge case: what if a plugin author still maintains a plugin, but doesn’t update it on Extend?
ddebernardy – then he answers the mail
Jane_ – if there’s a policy in place that un-updated plugins in repository go to bed after time, am guessing they’d be more likely to update there too

Meta tables was on the agenda but has been pushed to the July 22nd meeting.

Ddebernardy wanted to talk about bugs and committer workflow, but without rboren, hard to make any firm progress This topic might be discussed again on the July 22nd meeting.

westi posted “User experience for comment deletion undo / trash. (http://core.trac.wordpress.org/ticket/4529)”

The question regarding this ticket deals with the User Interface. There might be a poll in the future where users can vote on whether they want a link to a trash can or a simpe undo. Next was the discussion surrounding whether the stuff in the trash can should auto-delete or not after 30 days. The decision was that by default, trash will autoclear but there will be hooks available to override how long before things get deleted.

The results from the media survey were to be published the night of the meeting with screenshots but it hasn’t happened yet. Look for that on the dev blog at some point in the near future. Also, the poll results didn’t change much from last time.

Out of all the GsOC projects, all but one passed. The event management plugin suite for buddypress is the one not moving forward, though the student says he is going to keep working on it even though it’s no longer gsoc

To see the entire log file for this day which contains the fine details into the various agenda topics, head over to the WordPress Dev IRC Channel Log.

2

2 responses to “WordPress Dev Chat For 7-15-09”

  1. I think the plugin / theme developer mailing list is a great idea. Finding out what might affect my plugins is currently a little bit of hit and miss, and this list would solve that.

    Not sure about the plugin adoption idea. It’s a great idea if the plugin author actually chooses to put the plugin up for adoption, but I’m a little uncomfortable with the idea of doing it without their explicit approval (ie if you can’t get in contact with them).

    It’s all open source, so anyone can take the code and create a new plugin based on it, but actually transferring the original plugin to someone else without permission seems wrong.

  2. @Stephen Cronin – I agree, I think it’s definitely a good idea. Would solve the problem of plugin authors complaining that they never know what changes are done to core that breaks their plugin.

    I definitely think the plugin adoption idea is merit for another meeting to talk about. I hope plugin authors could chime in on that meeting to voice their opinion.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.