We were live.. Now we have video.
For those that missed the first discussion, here’s the video.
-
Samuel "Otto" Wood
Reply
You must be logged in to post a comment.
For those that missed the first discussion, here’s the video.
You must be logged in to post a comment.
Shane Pearlman, 
Ryan McCue 8:45 pm on August 15, 2012 Permalink | Log in to Reply
Thanks for putting this up; I had a schedule conflict that meant I missed this. Seems like a very interesting discussion in the hangout, looking forward to the further discussion here.
Samuel "Otto" Wood 11:29 pm on August 15, 2012 Permalink | Log in to Reply
I just want further discussion. By all means, please listen to the YouTube, comment on the discussion posts that Erick kindly made, and let’s hash it out. We can’t know what the community wants until the community speaks up. Tell your friends. Tell your enemies. Tell everybody. Spread the word:
WE WANT INPUT.
Let that be the word spread. More ideas, more input, excellent.
Eric Marden 12:58 am on August 16, 2012 Permalink
My 2 cents:
dotorg could be more like github
enable “social” coding, pull requests/patches (with ability to do code review), and more visible issue tracking (forum integration good, but could be more visible). This will encourage meritocracy. Plugins with traction will be obvious by the activity around their repos.
WP needs more plugins that provide “APIs” that other plugins can build on top of.
There are lots of doubled efforts happening in the plugin space, and so much duplicate plumbing. Drupal does this pretty well, with many modules providing the “guts” and no UI. Other modules then can build on a solid architecture but go nuts with the options, UI, and other bells/whistles that some devs like but others abhor. I’ve always wondered why I haven’t seen much/any of this in WP. There are some framework-y plugins/themes but nothing akin to providing the data model for “voting api” and other plugins providing the UI — one for “+1/-1″ style voting; one for “5 star” ratings, etc, etc. Quality APIs that are outside of the scope of core would allow less experienced devs to focus on parts of the stack they might be more comfortable with, and might be able to mitigate some of the more egregious code I’ve seen on dotorg.
Take up the invitation by Otto and help him review plugins.
If you’ve got the chops and the interest the best way to help others find vetted plugins is to vet plugins. If you don’t have the chops, figure out how to get them. A good way to learn is ask others to review your code. Another way to learn is to do code reviews. It’s easier than you think to spot “code smell” in other’s work even when you may be guilty of the same errors. Seriously, this is the one thing that would make the most impact — more eyes means that we can move past having stuff vetted for spam/phishing by 2 or 3 people to vetting code for quality, efficiency, performance, best practices, security AND spam/phishing.
Ryan McCue 2:56 am on August 16, 2012 Permalink
+1 for Eric’s idea of social coding. Often I see plugins that could use tweaks, or they’re _doing_it_wrong(), and being able to contribute a patch back quickly would be great. At the moment though, it’s a lot of effort to checkout the plugin, create a patch and submit it to the (broken) plugin Trac, especially when plugin authors don’t monitor this. I’d love to see something GitHub-style with editing in the browser instead.
Daniel Dvorkin 10:50 am on August 16, 2012 Permalink
+1 indeed. Lots of times we need to fix broken plugins for clients projects. It’d be really cool to be able to contribute those changes back to the main plugin in an easy way.
Aaron Holbrook 3:15 pm on August 16, 2012 Permalink
+1 for the idea of social coding as well
Jake Goldman 5:04 pm on August 16, 2012 Permalink
While more social coding and github functionality might be nice, I’m going to again bring this conversation around to *non-technical* users. The repository should be a simple, consumable, *trusted* source for plug-ins for general WordPress users who could care less about how socially a plug-in is built, and are immensely confused when they visit github.
Let’s not make this more complex for Joe WordPress Publisher in our attempt to make a repository.
Brent 7:18 pm on August 16, 2012 Permalink
+1 for easy patches/pull-requests to other plugins. Making it easy to submit patches to other plugins will raise the standard of quality in plugins.
Jake’s comments considered, this feature doesn’t need to confuse Joe WordPress Publisher either – he never needs to see it. It can be hidden away for developers looking for it, in much the same way Joanne WordPress Publisher never sees http://core.trac.wordpress.org/
Ryan McCue 9:02 pm on August 16, 2012 Permalink
+1 on Brent’s point, it can all be hidden away under the Developer tab on WP.org. I think filling out that tab with more tools would be great.
Jake Goldman 9:13 pm on August 16, 2012 Permalink
Again – all for it. I just think the primary objective right now is separating the wheat from the chaff. Part 2 is how do we more actively improve the chaff (and the wheat, I guess).
Brent 9:17 pm on August 16, 2012 Permalink
Focusing on “separating the wheat from the chaff” is also more achievable in the short term.
I’ll start another thread for the idea of achieving this through a better search algorithm.
Samuel "Otto" Wood 10:36 pm on August 16, 2012 Permalink
In separating the wheat from the chaff… who’s doing the gardening? By what rules do these gardeners operate? That’s the discussion I want to see.
You have free rein to argue it here, and I would *love* to do more hangouts when asked. So please, self-organize. Come up with a set of guidelines. Build them up. Revise them. When I see a team of self-organized folks ready to take on the challenge, then by all means, I will pass on advice, provide a location to organize, provide the needed powers to get the job done, etc.
Build that team of volunteers willing to get the job done, come up with a set of principles by which the job will be done, show that you’re capable of doing the job, and I will absolutely assist in any way possible.
Take charge. Get ‘er done.
Eric Marden 1:25 pm on August 17, 2012 Permalink
Social Coding *is* for non-technical users. Other than a review team, this is the most direct way, I can think of, to improve quality of the plugins in the repos for *everyone*. Yes, only devs will participate in the coding, but that’s already how it is now.
Tom McFarlin 11:35 pm on August 18, 2012 Permalink
@Eric – I agree but just to a point.
Social coding is for end user’s in that that who’s it generally benefits, but most end users don’t get those services. GitHub is built for developers by developers – trying to get the average company or Joe Publisher to figure out how to interact on there isn’t a good idea (this is coming from experience – even with newbie developers).
I think there should be two segments, so to speak: one for developers to communicate with developers (just like GitHub) and one for users to communicate with developers (like a forum of some sort). I’d even go as far as to say that the Stack Exchange model can detract a bit because a number of people are more concerned with getting their questioned answered or bugs resolved they are than obtaining reputation or badgets.
seiharris 6:07 am on August 20, 2012 Permalink
If there is to be any plug-in reviews, or vetting of plug-ins there needs to be first the guidelines in place with which to vet them against. I think these guidelines should be worked on now – since even if vetting isn’t put into practise yet, it will serve as the ‘go to’ place for authors wanting to do it right. It will also act as a good indication of what any future plugin review team would look at.
So while how vetting might / might not be done is still being thrashed out – should we start looking at the actual guidelines for plug-ins. Since this will be useful for authors now. If anyone has drawn up a rough draft list – then please post it. Otherwise I can start one up on Google docs, similar to the UI guidelines being worked on: https://docs.google.com/document/d/1ZWPeUSFVYlMxClmHFjuAXuekXcZsLso49G3bDRquHcs/edit?pli=1
Brent 6:54 pm on August 20, 2012 Permalink
@seiharris a Google doc looks like a good way to get into more meaty content around guidelines.
Shane Pearlman 7:22 pm on August 20, 2012 Permalink
@seiharris – that is a good point. Now that the core contributor handbook is done, I knwo that there is interest and intentions to create a plugin contributor handbook. Not sure (@nacin or @otto …) who is going to own it, but it makes a lot of sense that this should be a paired effort with the current conversation.
Japh 9:08 pm on August 15, 2012 Permalink | Log in to Reply
My apologies for not making it to the Hangout, I also had a schedule conflict. Had to drive my wife into work. THanks for recording it to YouTube though, I’ll watch back over it
Shane Pearlman 1:37 am on August 16, 2012 Permalink | Log in to Reply
Just noticed that you can’t see the text chat when re-watching. One of the questions was how do we measure and determine quality as a user.
metrics of quality:
base review (security, what it says it does, no errors / notices)
peer dev review (vetted by respected community members)
peer usability review (vetted by respected community members)
community usage (active installs, downloads, updates)
community rating (favorites, works, rating, reviews)
support level (# of threads answered)
anything else?
Brent 7:25 pm on August 16, 2012 Permalink | Log in to Reply
Which metrics to use for quality is very a important question.
Each of those sound great, except for community usage. My most popular plugin is by far my worst code. Many of the most popular plugins were also written many years ago, before many important WP APIs and before WP Coding standards.
Usage is a better measure of demand than quality.
The only thing I would add is “WP Coding Standards” to the base review.
Tom McFarlin 11:30 pm on August 18, 2012 Permalink | Log in to Reply
I’m a bit behind in chiming in on this and I’m doing my best to catch up so hopefully these thoughts will all be captured in the right thread. If not, my pre-emptive apologies
.
I like @Shane’s initial metrics of quality – I’d just like to add that there needs to be a line drawn between the technical areas that we’re discussing (GitHub-esque and ala Stack Exchange) and user-centered features.
First, I think that *all* developers should be using the Developer plugin. I’m not sure of a good reason why a user shouldn’t be using this.
Secondly, I think that the criteria that’s build into many of those sub-plugins (Log Deprecated Notices, Debug, etc, etc, provide a solid foundation of basic rules to follow. I think that plugins – before being released to the repository – should be evaluated against the rules those plugins. If passes, perhaps that’s good enough; otherwise, it isn’t approved.
Finally, I’m a fan of developers providing PHPDoc-based comments of their functions and variables. This definitely plays more into the developer-centric features, but I think that if we’re at all going to being hacking each other’s plugins, we need to make sure we understand what one another’s functions are doing
.
justinsainton 10:47 am on August 16, 2012 Permalink | Log in to Reply
My thinking is that something that could be implemented and experimented with in the short-term is a way to prioritize search results by the number of the plugin author’s core contributions. If their code is trusted enough for WP core – to me, that’s a massive indicator of being able to trust the code.
Jake Goldman 5:08 pm on August 16, 2012 Permalink | Log in to Reply
Agreed. This is exactly the kind of change we need – and this information is already being captured. In fact, we might just encourage more core contributions if they influence plug-in popularity.
What I think we need to figure out, however, is how to also elevate plug-ins those leading contributors / community members have vetted, but haven’t contributed to.
This goes back to – I think – the best idea in our conversation: users should be able to favorite WordPress.org users, and view plug-in’s favorited by their favorite users. Think what “Facebook Like” does for websites, for plug-ins… a feed / timeline of activity by favorite users. “Nacin just favorited ________ plug-in.”
Daniel Dvorkin 6:56 pm on August 16, 2012 Permalink
This would be really cool. And I think buddypress has this functionality? Only thing I’d like to argue again is for the difference between “Fav” and “recommends”. Actually I think Fav is a weird concept. It’s much clear to have “bookmark” and “recommend”, or something like that.
Jake Goldman 8:57 pm on August 16, 2012 Permalink
I agree that “Recommended” might be a better term. Though I’d like to think elite developers wouldn’t favorite poorly engineered plug-ins.
Tom McFarlin 11:37 pm on August 18, 2012 Permalink | Log in to Reply
+1 for prioritizing search results based on code. As mentioned in this comment, I think adherence to the basic Developer Plugin rules would be one place to start.
I think we need to be careful with a plugin author’s core contributions. Case in point: I love WordPress and I’ve been trying to actively contribute more to core *but* I’ve had some patches merged, some dismissed, and some I just don’t have time for because of outstanding work (all WordPress-based – themes, plugins, etc).
Perhaps a badge indicating that the author is a Core Contributor would be a way to help enforce this?
Aaron Holbrook 3:16 pm on August 16, 2012 Permalink | Log in to Reply
So glad you guys have video of this, sorry I couldn’t make it – had some family stuff that needed doing.
Brent 9:20 pm on August 16, 2012 Permalink | Log in to Reply
What sort of ranking algorithm is used for plugin search atm?
Many of the suggestions from the video aimed at “separating the wheat from the chaff” could be achieve through a better search algorithm.
Discussions around dot org plugin reviews pick up speed | WPCandy 7:38 pm on August 17, 2012 Permalink | Log in to Reply
[...] up dotorgplugins.wordpress.com, a simple P2 theme install to host the discussion. To quote Otto, straight from the P2, on seeing this discussion take place:You have free rein to argue it here, and I would *love* to do [...]
scrollpost 3:26 am on August 18, 2012 Permalink | Log in to Reply
IMHO as a WP user that’s become sophisticated over time – low hanging fruit – enhance the plugin repository with better info, sorting, tagging. Social coding is a great idea but the “ownership” of the developer needs to be considered. Don’t cater for the lowest common denominator, instead try a rating for user level to work with a plugin. Better RSS feeds of plugin releases. **Most of my ideas are structural and cost little and require no maintenance.** One more controversial idea – add advertising to the repository to pay for the enhancements.
Improving WordPress Plugins - Tom McFarlin 8:44 am on August 20, 2012 Permalink | Log in to Reply
[...] Last week, an impromptu discussion about the state of plugins grew into a much more serious talk. So much so that what started as a Twitter conversation moved to a Google Hangout then migrated to a blog. [...]
H2GD Part 14: battles with PHP's serialize and WordPress cache - herb miller 11:55 am on August 21, 2012 Permalink | Log in to Reply
[...] NOW, just recently I’ve been following a video and associated comments along the lines of “Improving the WordPress.org plugin repository” [...]