Note to self: schedule bug hunts/patch testing sprints for Sun-Mon a week from now and Thurs-Sat in mid-November, per IRC dev chat today. Announce on dev blog tomorrow.
Updates from jane RSS Hide threads | Keyboard Shortcuts
-
Jane Wells
-
Jane Wells
-
Jane Wells
Use this thread to brainstorm ideas for better ways of crediting contributors (and third-party products that ‘contribute’) to the project (on wordpress.org and/or otherwise).
-
Millan
Since the 2.9 will bring major overhaul of Media Library and image management, maybe it’s a good idea to implement several new things regarding easier use of images. Infact, most of the things needed are already implemented.
Many WP themes use third party library TimThumb for generating thumbnails (very poor transparency support, very slow), and all that is already built in in WP and implemented much better, so WP core can get one more function (a php file that can be used to serve images with resizing and effects capabilities) that will be a replacement for the TimThumb functionality.
-
Jane Wells
Sorry, I’m not sure how this relates to creating a credits page on wordpress.org? Sounds like you want to discuss an actual core feature change, which is better done on Ideas or Trac.
-
Millan
Sorry, you are right, I will add this to Trac.
-
-
-
Mark Jaquith
Trac usernames == WP.org user names. WP.org now has BuddyPress profiles via http://profiles.wordpress.org/ Someone could code a tool for WP.org that takes a list of “props” handles and converts them into an array of WP.org members with their full name and URL. If we got better about using the exact Trac username when giving props, this could be used to make a highly accurate list of code contributors for a list.
I also think that you should get a “badge” or something on your WP.org BuddyPress profile once you’ve gotten enough “props” in commit messages. There could be bronze, silver, gold medals for 1, 10, and 50 “props” messages. They could link to a page telling people how to contribute patches. This could be a way of leveraging curiosity and competition into more Trac involvement.
I also floated the idea of having an “about” page within the WordPress admin that could feature the core contributors with a Gravatar image, and a short blurb. That might be a good way of humanizing the software and a Google-friendly replacement for the default blogroll of days past.
-
Alex (Viper007Bond)
That sounds awesome and would further promote the community aspect of the new profiles.
-
willmot
Sounds like a great idea. We could also have embeddable badges so that people can add them to their own blogs.
-
Aaron D. Campbell
I think the idea of using the wp.org profiles is the best solution, and I’m a fan of the badge idea. I’m not sure about the about page in WP admin. I don’t dislike it, but I’m not sold on it. It seems like it would be a rather large page. Maybe something that should be kept on wp.org and linked to from WP admin?
-
-
demetris
This is a first draft of a list of third-party projects used in WordPress 2.9-rare:
http://codex.wordpress.org/User:Demetris/Credits
When ready, this list could be used in an official Credits/Acknowlegments page in wp.org, or maybe also in an About page within the WP admin (see Mark Jaquith’s idea above).
As I am not very familiar with the inner parts of WP, please feel free to add things I’ve missed, remove things that are being phased out, etc. etc.
Maybe I’ll open a Trac ticket too, to better monitor this.
-
Aaron D. Campbell
Someone else probably knows better, but I don’t think that Prototype JS, Script.aculo.us, or Cropper are actually used in WordPress. They’re still packaged with it in case plugins use them, but WP doesn’t use them.
I’m not sure if you wanted everything that was “packaged” or everything that’s actually “used”
-
Peter Westwood
List looks good.
CodePress – is bundled but not currently used I think
PHP-Gettext – don’t think we use this anymore as we use the pomo libs from glotpress I think.-
demetris
Thanks, Aaron and Peter. I split the list in two for now: Used and Bundled:
-
-
-
-
Jane Wells
Use this thread to brainstorm ways to make plugin repo more secure in terms of what code makes it in there.
-
Jonathan Dingman
Right now, people can submit their plugin for approval, be accepted (or denied), and upload their plugin. Then, they can make updates. Ok, so far so good.
While I don’t think it’s scalable to have code reviews on every little code update of every plugin, which would turn us into the Apple AppStore, I do feel there ought to be some sort of level of accountability. I can’t pinpoint exactly how it should be in effect, but I feel there needs to be — beyond someone going onto IRC and reporting it to MarkR (as an example).
Maybe even having a “report form” on each plugin page, letting people flag plugins as “this plugin requires a link back” or “this plugin has known vulnerabilities” or “this is spam” and have someone, even a volunteer, manage it, and/or forward the suggested action to take to an Automattic employee.
I feel that there needs to be some additional level of accountability set in place for plugins, since it’s becoming an even more important part of WordPress than it was just a couple years ago.
-
Millan
Good points, Apple AppStore level of control is just insane and it’s not a good way to go. Right now, except for approval of plugins I think that there is almost no control over what’s happening there (correct me if I am wrong).
But first thing needed is a cleanup. There are so many plugin that are not maintained or even downloaded for years. I am not exactly sure, but my guess is that no more than 2000 of almost 7000 registered plugins are active.
-
Ken
Rather then approval ala AppStore, plugins that got and pass audit could have a badge… one that would be desired, but not required. We could concentrate on popular plugins first, and ones marked by Dingman’s (crowd source) flagging suggestion. I think that the review should primarily audit security on the plugins, not indepth quality reviews
. But I agree with Millan, the repos need some cleaning. On the mailing list, deleting was brought up, but that’s not “exactly in the open source model”. Rather, I’d like to see some tag that marks a plugin abandoned (as judged by review or author’s explicit declaration, to prevent old but good plugins’ removal), and that removes it from the default search only. It’d still be findable for someone who’s interested in reviving it though a separate search. A tag for “unsafe” could be useful too, maybe block installation though the WP admin but still allow .org download (for someone to fork and fix).
With the new compatibility feature, something has to be workable here
-
-
-
Aaron D. Campbell
It seems to me that there are two basic approaches here. Either put together a team to do this or crowd source it. Both have their advantages and disadvantages. Obviously a team would be reliable, but overwhelmed by the amount of code that needs to be audited (however, there are probably some ways to mitigate this, but I’ll get to that in a second). I’m really worried about the idea of crowd sourcing the security of code. Mostly because most of the “crowd” doesn’t know what they’re doing. The vast majority of the complaints you get will be because the person couldn’t get it to work, there was a plugin or theme conflict, or because they blame it for something else that they did wrong. In theory crowd sourcing is nice…mostly because it spreads out the work load, making it seem manageable. I’m just worried that this isn’t something that can be handled this way (unlike plugin compatibility with WordPress versions, which I think would work well if crowd sourced).
Maybe there could be a sort of hybrid system where it’s crowd sourced and then passed to a team of people that check out the plugins that were reported, but I worry that this would increase the workload of the team rather than decrease it.
In the spirit of decreasing that workload, I have a couple ideas for that:
Some people could be “white-listed authors”, and their plugins wouldn’t need to be checked. For example, you could white-list all Automattic employees as well as people like Joost De Valk (and of course, in my opinion people like me as well). It seems like this could greatly reduce the number of plugins as well as the number of updates that need to be checked.
Also, it seems like there could be some effort put into highlighting *possible* bad code. Maybe certain functions (including usage of the WP_Http class or functions that write to the file system) or a certain amount of changed code would raise a red flag?
-
Jonathan Dingman
Junsuijin, sivel and myself were talking today and brought up this idea.
Requires no moderation and it could help strengthen the plugin community as whole.
Recommendation: Don’t allow any linking within description, FAQ, installation, notes, screenshots, or any place. ONLY allow the two links, plugin link and author homepage link. All existing links (and future links), strip the hyperlink and have it display as thislink.com instead of the complete hyperlink.
Additionally, removing these links, it would force plugin authors to actually put real information in each section. Right now, there are a number of plugins that have just a link as their FAQ, going to their homepage. I feel this is bad usability for when users are installing a plugin via the web and because it’s just one more step for them to take to read about the plugin. It shouldn’t be that difficult to read the FAQ of a plugin. All information should be provided on the wp.org page.
How would this help?
Links would still be there for information purposes if someone really needed to go to it.
It would help weed out bad plugins that really don’t provide any value to the community (sort of
It would give spammers less to work with and force plugin authors to be more intentional about how they package their plugins
Would almost eliminate entirely, the SEO spam problem in the repo right now-
Matt
While I was part of this discussion I don’t agree with this necessarily. I of course prefer not to find these types of links in the docs, but removing all the links is a bit harsh. There are plenty of valid reasons to include links such as to an external support forum, or license file.
I would however like to see where if the majority of a section is linked nothing displays at all. For example people drive huge amounts of traffic to their sites by only placing a link in each section saying, visit my site for this information.
-
-
-
alphawolf
Instead of reviewing every single plugin, why not start reviewing or removing all the plugins rated less than 3 or 2 stars by the community? Or mark insecure or sth. like that (not open to the public until it has been reviewed or banned forever) …That would even give the rating system a meaning.
-
Matt
Ratings do not necessarily mean that the code is bad or insecure. It could just be a poor implementation. In some other cases you will find that ratings go down due to retaliation for say not helping in the support forums. Or I have heard of other authors giving bad ratings to competing plugins. I think removing a plugin based on ratings would be unwise.
-
alphawolf
Good points, but your first ones are potential causes for bad or insecure code anyhow. A plugin with poor implementation could mean the author doesn’t really care about WP coding standards (which include security standards) and an author who doesn’t seem to care about his plugin (as of giving support in the forum) could result in an outdated plugin not matching the security aswell.
But I get your point.
-
-
aarondcampbell
While it may not be a definitive solution, I’d say that low rated plugins that have a decent number of ratings (maybe 50+?) would probably be ones that could be checked first.
-
-
Mark Barnes
There’s a balance that needs to be struck. It would be relatively easy to write a reasonably popular plugin, then make a change which (for example) sent the users password to a remote site upon successful login. Only human review could prevent that, I think. On the other hand, I don’t want to wait for human approval every time I commit.
-
Aaron D. Campbell
Was there any sort of resolution on this? Or are we still brainstorming?
-
-
Jane Wells
After several quietish weeks in the dev chat, this week’s agenda post was brimming with suggested topics. It’s really too many to fit into an hour, so I’m listing them all here in order of priority based on relevance to the on-time release of 2.9, along with the amount of time I’d like to allot to discussion. Since we’re short on time, we can continue discussions on a bunch of these here on the blog, in trac tickets, and/or prioritize for a future dev chat.
- 2.9 Media features update (30) — image editing, oembed, UI, post thumbnails, gallery/albums, custom image sizes
- Brief discussion of ticket etiquette (5)
- SimplePie future (5)
- Plugin Repo: how to make it more secure (5) — I think this deserves its own dedicated discussion. Would like to use this 5 minutes just to identify who is most interested in brainstorming ideas around this.
- WordPress.org: credits to other products and contributors (5) — This should really fall under discussions around changes to wordpress.org site, and will also need more time. Again, would just like to identify people interested in brainstorming on this.
- http://core.trac.wordpress.org/ticket/10882 (5) — discussion has already happened on the ticket (and its related ticket), so will just get an official decision from core team. Ryan will attend the chat.
- IRC OPs permissions for sivel and Viper007Bond (5) — meant to have been added, but hasn’t happened yet, just a check in with Matt (if he attends) to find out status of adding them as OPs.
I’m at Ryan’s for today’s meeting, and we are working on 2.9 stuff, so keeping this meeting fast and on schedule will help us all.
-
Jane Wells
September 24 dev chat agenda:
-Plugin directory policies
-Any core code questions that people need answered to help them finish a patch against 2.9 -
Jane Wells
Suggest agenda items for Sept 17 dev chat.
-
Jane Wells
Check in on status of the media features that we haven’t talked about in a couple of weeks.
-Basic image editing (Azaozz)
-Gallery improvements/Photo Albums (I’m still not super clear on which way we decided to go with this)
-Embeds (Viper007Bond)
-UI update (Jane)-
Alex (Viper007Bond)
The embeds framework has been mostly done for a week or so. It should probably be committed for further testing and other handlers be written (VideoPress for example).
-
Alex (Viper007Bond)
Actually, let me get the phpdoc and some other minor tweaks in first. Might as well get it done right the first time rather than adding more stuff in later.
-
-
-
Matt
OPs for the #wordpress IRC channel.
-
Jane Wells
Matt’s adding Viper007Bond and Sivel as OPs.
-
-
Peter Westwood
get_post_meta bug – http://core.trac.wordpress.org/ticket/10803
-
-
Jane Wells
Topic suggestion for Sept 10 chat?
-
Jeffro
I’d like to know if we could talk about the way releases are handled on the development blog. Taking a look at posts in the past regarding releases, the display of information, links to changesets or the lack thereof are all over the map. I think it would be beneficial for the team to share a template to use for Release type posts on the dev blog.
One other thing I wanted to know. Why is it that typically, to upgrade WordPress you need to upload the entire package even if just a few files were changed? For those folks where auto upgrade does not work and they do not want to wait for 20 minutes to upload the WordPress package, is it safe to just upload the changed files to perform the upgrade? This ties into my first discussion point.
-
Jane Wells
“To share a template to use for Release type posts on the dev blog” implies that there’s a template to share, which there isn’t.
Announcement posts are written individually and tend to vary in style based on what kind of release it is and who’s writing it. Matt’s posts are chatty and highlight the headline features, Ryan’s posts are practically haikus that link to the .zip, etc. I agree it would be good to have a set of information that is included each time, though, for whichever author to check against. Not sure if this needs to be a discussion point in the chat, though… might make more sense to put together a list of items to include, post it here, and invite feedback, especially since all the announcement authors won’t be in the chat today. There have been past releases where the announcement says you can just upload/overwrite specific files.
-
Dougal Campbell
I’m still drafting out a blog post with many ideas for improving (I hope) community information and such. But just a quick note of what I think about regarding a “template” for releases:
In each new feature release, there are changes in core along these lines:
* new functions added
* existing functions modified (new arguments? return type changed? side-effects?)
* existing functions deprecated
* deprecated functions removedAnd where I say “functions” you could also substitute “classes”, “files”, “action/filter hooks”, and “global variables”, really. Fortunately, the first item is most common, and the other three cases are relatively infrequent.
In order to help the third-party plugin/theme development community stay up-to-date with changes in core, I think it is very important that these changes are documented in a standard fashion. Currently, we pretty much just have to keep our eye on changes in the SVN repo and/or Trac, and hope that we don’t miss something important. I’d like to us to have a known place where one could see these sorts of internal technical changes detailed in a formal way.
Is there a way to automate it? I don’t know if there’s an existing tool for it, but at least some of it *could* be automated. It shouldn’t be hard to automate detection of new functions, classes, and files. And deprecation tagging should be easy, too. Detecting changes to existing functions could at least be partially automated, if it’s something obvious that affects the @param or @return tags in the phpdoc. Other changes (like a new global variable related to a new feature) might have to be documented manually. And of course, when I say that automating some of these things should be “easy”, I mean compared to trying to track them by hand and write it all up at release-time.
BTW, I wish I could participate in the dev IRC chats, but they take place right around the time that I’m trying to wrap up work and get ready to head home, and my family is a higher priority
-
-
scribu
For the second part, there was some discussion on downloading only changed files. Not sure if there’s a ticket on trac for it though.
-
Mark Jaquith
There’s a way to do this in Trac, but it’s not immediately obvious. I can share in the chat.
-
Dougal Campbell
It’s fine that various people do their own writeups about releases in their own style.
But I think that there could be some value to codifying/formalizing some sort of “official announcement style”, even if it is posted separately (Codex?), and merely referenced in the other announcments.
This is something I’ve been kicking around in the back of my brain for some time now, and there are hints of it in the postings I’ve made recently on wp-hackers, my own site, and in comments elsewhere, regarding the recent worm incident. I’m working on another blog post about it now.
This isn’t the place for a lengthy discussion about it, however. After I finish putting my thoughts down, I’ll post a note about it on wp-hackers, and I’d like to see some more discussion there about the pros/cons/costs/benefits of formalizing some release procedures and information.
-
Jeffro
Ok, guess I should get on the ball and rejoin the hackers mailing list.
-
-
-
scribu
What’s happening with the GSOP projects? MPTT and the Search API especially.
-
Alex (Viper007Bond)
Search: http://wordpress.org/extend/plugins/search/
Been using it on my blog for a while. Works great.
-
Jane Wells
I’m getting updates on integration from all the GSoC mentors, but doubt I’ll have them all by today’s meeting. When they all come in, there’ll be a summary post on the dev blog. Held off on posting about it so we could say what was happening with each one (as opposed to just saying they were finished).
-
-
Jane Wells
Suggest topics for the September 3rd dev chat.
-
Jane Wells
Status check on the various features people said they’d work on for 2.9. Will dig up the list from chat a month and a half ago, hoping there’s been some progress.
-
Denis de Bernardy
-
Denis de Bernardy
I’ll do http://core.trac.wordpress.org/ticket/10201 after the previous is committed.
-
-
Jane Wells
Yoast working (and discussing with westi) on allowing login and register pages to be templated
-
Matt
Meaning — CSS?
-
Peter Westwood
No meaning as a template file like login.php
So you can completely intergrate the login into your CMS
With possibly other stuff on the page as well -
Matt
I think we lose a lot of flexibility in future updates to the login system if we allow the login logic to be overwritten, I’ve seen numerous full integrations done using just CSS though. It’s trivial to change colors, replace logos, etc. It’s what CSS was designed to do.
-
Matt
I would be okay with a wp_login_form() template tag that could be embedded other places, though.
-
Peter Westwood
Trying to understand what we would lose with the following:
Refactor current login code to be template tag able
Allow a theme to completely change html using a login.php template file
Add pretty permalink support for the wp-login.php page.As long as the themes are using the template tags we use in the default we have the same flexibility?
-
-
Jane Wells
It’s being discussed right now in dev chat, just adding it here so will remember to include for post-meeting post.
-
-
Jane Wells
Andy Peatling, http://core.trac.wordpress.org/ticket/10467
Jane Wells
Agenda for 8/27/09 dev chat:
-Comment meta / generic meta. (Westi)
-Page comments in default theme (Joseph/Westi)
-whatever else
Simon 4:38 pm on November 5, 2009 Permalink |
What happened to these? I’m guessing they won’t make 2.9? 3.0 instead?