Digging the make blog redesign. I notice that the “learn more about mobile” link points back to the home page. Can this be updated to point to the mobile make blog? Thanks!
Recent Updates Toggle Comment Threads | Keyboard Shortcuts
-
Eric
-
Mert Yazicioglu
Profiles – Screencast
As you know, I’m worked on enhancing profiles.wordpress.org as a part of GSoC’13 and this is my final update. My last task was to prepare screencast to briefly explain the new design and here it is!
It was a great summer and I would like to thank @boonebgorges, @coffee2code, @jenmylo and everyone who supported me throughout the summer with their comments and feedbacks!
Looking forward to the deployment of the new design!
See you later!
-
Amy Hendrix (sabreuse)
Congratulations, Mert! Can’t wait to see this design in the real world!
-
Mert Yazicioglu
Thank you very much, same here!
-
-
Eric Amundson
Great job, Mert! Looks great and is a nice improvement over the current profiles!
-
Mert Yazicioglu
Thanks, glad to hear that!
-
-
Siobhan
Looks awesome. Congratulations on a great job. Looking forward to the new profiles going live.
-
Mert Yazicioglu
Thank you very much for your kind words, much appreciated!
-
-
@mercime
Congratulations Mert! Looking great! Been waiting the whole summer for the reveal
Cheers to your mentors as well. -
Jose Castaneda
That looks awesome! Very nicely done.
-
-
Jen Mylo
Added @krogsgard as an author here, as he’s getting started on the Make home site work.
-
Mert Yazicioglu
Profiles – Weekly Update 13
As you know, I’m working on enhancing profiles.wordpress.org as a part of GSoC’13 and this is my thirteenth weekly update regarding how things are going.
This past week, I fixed all the bugs @coffee2code reported and also wrote a plugin for WordPress to install on blogs under the make subdomain so that we can track the publishing activities on these blogs as well. You can see the plugin here: new-blog-post-notifier.php. Also, updated the documentation to reflect the addition.
This week, as you know, is the final week so I’ll be wrapping things up and preparing a screencast. Also, Jen will probably be providing us some feedback regarding the UI/UX of the new profile design.
See you next week!
-
@mercime
Congratulations @merty !
Looking forward to the screencast and final reveal -
Mert Yazicioglu
Thanks. me too!
-
-
-
Ian Dunn
Support Expectations for Meta Plugins in the WordPress.org Repository
For plugins that we release into the WordPress.org repository (like CampTix and Tagregator), what should our support policy be?
Since we have a lot of things we want to accomplish, and a limited set of resources, my opinion is that we should provide product support, but not user support. i.e., we should fix bugs and security vulnerabilities, but not help people who are having trouble using the plugin, or who want to customize it to fit their specific needs.
The would ensure that the quality remains high, but would avoid us getting bogged down with doing other people’s work for them.
We could manage expectations by having something like this in plugin description:
Support Expectations:
We created this plugin to scratch our own itch, and are happy to offer the code to the community in the spirit of open source. We are only able to provide limited support, however. If you find a legitimate bug or security vulnerability∗, please let us know; we take those seriously and will fix them.
On the other hand, if you’re just having trouble using the plugin, or making it fit your specific needs, then you’ll need to solve the problem yourself, hire a developer, or get help from the community.
∗ If you do find a security issue, please disclose it to us privately by sending an e-mail to [email protected], so that we can release a fix for it before you publish your findings.
What are everyone’s thoughts on that?
-
Ipstenu (Mika Epstein)
I think that’s reasonable.
as long as that sort of thing is upfront, volunteers can point folks back to the plugin page for the “But WHY can’t I have them install it with unicorns!?” -
David Laietta
I think that the wording and expectations are reasonable as well. I am still of the opinion that the only users who would take the time to search this out and install will be aware of the work being done in the background (to an extent), and be more cognizant of the fact that this is even more bleeding-edge than your average plugin.
-
Mike Schinkel
Makes good sense. But maybe provide links to the different places where they can provide support from the community? Maybe include StackExchange’s WordPress Answers in that list of support too?
-
Ian Dunn
Hmmm, that’s an interesting thought. On the one hand, I like the idea of directing users to specific resources which best fit their question, but on the other, it’s nice to have everything centralized too, to avoid fragmentation, duplication, confusing users, etc. Not sure which one is better.
-
-
Siobhan
On the one hand, I think this makes good sense since support is such an ongoing and often onerous task.
However, on the other, we should consider the example that it sets to the rest of the community. Decisions made in relation to wp.org have wider ramifications as they tell the world that “this is the official WordPress way” of doing something. If I was a plugin developer, I’d be looking to wordpress.org to set the standards for what support I should provide. With a support statement like this attached to a wp.org plugin, we’re endorsing this sort of minimal support. Is that what we want to do? And if we don’t, are we prepared to say to other people “we want you to help users solve their problems, but we won’t be doing it ourselves”?
-
Ian Dunn
I think that’s a really good point to bring up.
I guess for me it hinges on the decision of what do we think are fair and reasonable expectations to have for developers who release plugins in the repo, regardless of if they’re from the Meta team or not. I know we’d all agree that fixing security bugs is a requirement, and that in most cases fixing regular bugs should be expected, but beyond that it becomes more grey.
Even with a moderately popular plugin, the amount of time it’d take to fully support all the requests that get posted can quickly become a burden that takes time away from other priorities, and the attitude that many users have often leads to a kind of “compassion fatigue”, where devs just get tired of constantly being asked for things from people who don’t contribute anything back.
So, do we think it’s wrong to only provide bug/security support? Personally, I don’t; I think that it’s a practical solution to the problem. It keeps the developer accountable to maintain the quality of the plugin, but without overburdening them; and it asks the users to contribute something back (even if it’s just fixing their own problems).
Having said that, I’m open to other opinions. If we were to provide full support, what are the options? A few ideas:
- Coordinate volunteers from the community to provide 1st level support, and pass the questions off to a developer if it looks like a bug or is particularly difficult to troubleshoot.
- Hit up Automattic, [Blue|Dream]host, etc to hire someone to work on the support forums in general, with particular attention paid to Meta plugins.
- Just bite the bullet and have the dev who maintains the plugin do full support, with the understanding that this will take time away from other projects.
-
-
@mercime
How about this at the beginning of the plugin description:
Then in next paragraph add info about the plugin and about not providing support for customizations, etc.
That way, regular users would not likely install the plugin, hence nor support questions (crossing fingers).
-
Andrew Nacin
I don’t understand why we’d put any code into the WordPress.org plugin repository unless we expected that people would use it on their own sites, and we are okay with providing support. I don’t mean resolving feature requests. I don’t mean writing CSS for users. I don’t mean customizing it for their site. But I do mean diagnosing and addressing bugs. And I do mean helping users who struggle to get it working — it likely points to deficiencies in the plugin’s steps to set it up and that user will only be the first of many to struggle.
This also, incidentally, sets a terrible example. Earlier this week, I noticed the “support expectations” in the Tagregator readme and became instantly disappointed that the “wordpressodotorg” username was assigned to it. This is the antithesis of what we push for and believe in.
Do we really need to spell out that we only support things in “limited” fashion? Is it really difficult to address valid support requests and decline to do someone else’s work for them on a case-by-case basis?
The plugins directory is not our dumping ground for internal or pet projects. It is a public directory aimed at users. If the plugin is designed for us, and isn’t designed to be used by others (whether it can be or not is a different story), it should go into meta.svn.wordpress.org. We’ve gone over this previously on this P2. The only time a plugin should go into the WordPress.org plugins directory is if it a solid general-purpose plugin, and that we intend to support it.
-
Ian Dunn
I don’t understand why we’d put any code into the WordPress.org plugin repository unless we expected that people would use it on their own sites, and we are okay with providing support. I don’t mean resolving feature requests. I don’t mean writing CSS for users. I don’t mean customizing it for their site. But I do mean diagnosing and addressing bugs.
I agree with that 100%.
And I do mean helping users who struggle to get it working — it likely points to deficiencies in the plugin’s steps to set it up and that user will only be the first of many to struggle.
I agree that those situations point out areas for improvement, but I also think those things things are often easily solved by RTFM’ing, and I don’t see any inherent reason why those would be blockers for making it available to everyone.
I don’t see product support as “minimal” in any way; it’s just the opposite. I think it covers 90% of users. The other 10% who want specialized features or can’t get it working are a vocal minority.
Even if we only have the resources to support the 90%, that’s still making a valuable contribution to the community, and the remaining 10% still have other means of getting help (other users, forum volunteers, paying a developer, etc).
To have a perfectly good and useful plugin sitting on the shelf just because it only meets the needs of 90% of users instead of 100% seems like a waste to me.
This also, incidentally, sets a terrible example. Earlier this week, I noticed the “support expectations” in the Tagregator readme and became instantly disappointed that the “wordpressodotorg” username was assigned to it. This is the antithesis of what we push for and believe in.
I’m happy to either remove the wordpressdot attribution, or change the support expectations, based on the outcome of this discussion. The first few days of comments were positive, so I went ahead with it, but nothing is set in stone.
Do we really need to spell out that we only support things in “limited” fashion?
Since many users have unrealistic expectations, yeah, I think it helps to let them know up front what they should expect, regardless of what level of support we decide to offer.
Is it really difficult to address valid support requests and decline to do someone else’s work for them on a case-by-case basis?
Difficult? No. Time consuming? Yes.
And why say it 100 times when you could say it once?
Also, why make people invest time in installing/configuring/using the plugin, only to find out down the road that we don’t provide the level of support they want, and so they have to start all over again with a different plugin?
The plugins directory is not our dumping ground for internal or pet projects. It is a public directory aimed at users. If the plugin is designed for us, and isn’t designed to be used by others (whether it can be or not is a different story), it should go into meta.svn.wordpress.org. We’ve gone over this previously on this P2. The only time a plugin should go into the WordPress.org plugins directory is if it a solid general-purpose plugin, and that we intend to support it.
I think Tagregator is a solid, general purpose plugin, at least as much as any other; no plugin can be everything to everyone. but there’s nothing specific to WordCamp.org about the functionality. It’s an early version that hasn’t reached maturity yet, but on a whole, it’s much closer to something like CampTix than it is to most of the one-off plugins in the Meta repo.
I think it’s better to release it, and let it be useful to other people, than to have it hidden away where it helps no one but us.
…and that we intend to support it.
I wasn’t aware of any decision about that, which is why I started this discussion. Rereading the other thread, I don’t see anything in your comment or anyone else’s that spells out a support requirement for releasing something in the WordPress.org repo.
If the decision has already been made and I missed it, that’s fine, I’m happy work within those guidelines; I’ve just never seen it written anywhere, so I thought it’d be useful to discuss.
-
Siobhan
There are a few issues at stake here. The first is the phrasing used in the Support Expectations outlined above, the second is a broader issue around what support people should expect.
1. There are specifically a few phrases in the support expectations that are quite distancing. These are “legitimate bug” and “just having trouble using the plugin”. This sets up a dichotomy between “bugs” on the one hand, and “just” having trouble on the other. Often the two are not mutually exclusive and a user may not even know what is a bug and when they’re simply struggling. Also, using the word “legitimate” tells the user that bugs are perfectly reasonable, that they will be taken seriously, but “just having trouble using the plugin” is your own problem, not legitimate, and you need to figure it out or pay someone else to (which may result in a situation in which a hired developer finds a bug that was causing the problem).
This is after telling people that we’re “happy to offer the code to the community in the spirit of open source”, i.e. we, wordpressdotorg, are setting the standards for how to behave in an open source community. Releasing code is a standard we do want to set, but providing limited support is not. Having the two things jumbled up together sends out mixed messages.
2. The wider issue is about what support we should provide for plugins that wordpressdotorg publishes in the repo. Given that Automattic provides support for its plugins hosted in the repo, I’m not sure why the decision has been made to not 100% support those published in the repo under the username wordpressdotorg. This gives the impression that while Automattic is willing to fully support its plugins, wordpressdotorg is not.
WordPress.org sets standards, whether that’s writing code or documentation, translating, providing support, or any of the other things that are involved in open source. We don’t always get it right, but we should try, because as soon as we stop trying other people will stop too. Dogfooding isn’t just about code, it’s about ethos. WordPress is all about users, and one of the best ways we can demonstrate that ethos is by fully supporting those users.
All that said, there are practicalities that need to be worked out with regards to offering full support. It’s really the developer’s responsibility to figure out who’s going to offer support. Yes, many people don’t do that, but that doesn’t mean that it’s okay for us to not do it too. Plugins released as wordpressdotorg should be supported by wordpressdotorg. There are a few options for this:
1. The plugins released by Automattic under wordpressdotorg could be supported by someone from Automattic. There’s a large team of Happiness Engineers – why not find someone from that team to be responsible for Automattic-released .org plugin? I’ve heard talk of non-coders doing some work on .org, this would seem to be a perfect way in.
2. There’s a large support team that constitutes an important part of WordPress. Responsibility for supporting .org plugins could be taken on by volunteers from the support team. If this is the way to go, we can discuss it at our weekly chat and see what we can come up with.
3. As you said “just bite the bullet and have the dev who maintains the plugin do full support, with the understanding that this will take time away from other projects.” Yes, it would do that, but we expect that of others so why not ourselves?In any case, this is an important discussion to have, so it’s good to see it raised in this thread. Hopefully between us we can come up with a solution that is clear, fair, and that fully supports our ethos.
-
Ian Dunn
1. There are specifically a few phrases in the support expectations that are quite distancing.
I agree that it can be improved, if we decide to keep it. One of the reasons I started the thread was to get feedback, so I’m glad that you pointed those out.
Given that Automattic provides support for its plugins hosted in the repo…
I’m not sure it always does. There are some plugins, like Jetpack and Facebook, that definitely are support, but it seems like the majority aren’t. For example, WP Super Cache, Akismet, HyperDB, Batcache, EditFlow, CoAuthors Plus and SyntaxHighlighter Evolved all have mostly unresolved threads, and many with no replies.
This gives the impression that while Automattic is willing to fully support its plugins, wordpressdotorg is not.
I’m not sure that’s a fair comparison to make; Automattic is unique in the community because it has a huge team of full time happiness engineers, while most companies and freelancers don’t have those kinds of resources, and the contribution teams are mostly made up of volunteers.
It doesn’t make a difference for someone like me who’s job includes working on these projects, but for a volunteer I can see it being a burden. When I was doing client work, there were always limits to how much time I could spend on plugin support and other volunteer projects. Even for people who do it as part of their job, there’s still way more work to do than hours in the day, so things always have to be prioritized.
I agree that product support (i.e., bugs and security issues) should be a priority, and that user support is a nice thing to have, but I don’t personally feel like it should be a higher priority than building new features and tools that will make an impact for the community.
WordPress.org sets standards, whether that’s writing code or documentation, translating, providing support, or any of the other things that are involved in open source.
I agree about setting standards, but I don’t necessarily think that means we have to be everything to everyone. I think it’s perfectly reasonable to say that we have X amount of resources, and we’ve decided to prioritize projects Y and Z. No matter what, we’ll always be saying no to somebody, it’s just a matter or who.
I feel the same way about any plugin author; I think it’s fair to expect that they fix bugs and security vulnerabilities, but I don’t think it’s fair to say they have to support feature requests, customizations and people who have trouble using the plugin.
But regardless of all that, it feels like in the minority here, so I’m happy to consent to the group. I’ll remove the support expectations from Tagregator’s readme and support it myself for now. If we get lots of requests, then I’ll look into asking for help from HEs and/or forum volunteers.
-
Alex Mills (Viper007Bond)
SyntaxHighlighter Evolved all have mostly unresolved threads
That plugin is purely mine and perhaps shouldn’t have the Automattic flag on it. It only does because I worked on some of it on company time.
All of my plugins are pretty much unsupported except for bug reports and fixes. I just don’t have the time.
But I’d rather release an unsupported plugin than not release it at all.
-
-
-
-
-
Jen Mylo
If it’s going in the repo as a dotorg-made plugin, we should support it, period, just like we do the core software. What this means is rallying some people who want to be support volunteers and monitor the forum for these plugins, and escalate to developers when bugs are found, not that the devs should switch to being support people. Basically, plugins we dev officially should have open development/opportunities for community contributions, and community members contributing to support and docs.
(*cough* core plugin *cough*)
-
-
Sam Sidler
Documentation Issue Tracker Specification
The Docs team tracks, modifies, and improves documentation across the WordPress project including in: Core, the Codex, the upcoming Handbooks, and other parts of WordPress.org and related websites. Throughout the project, code and design issues get tracked in trac (both the core and meta tracs), but this method isn’t the most efficient for tracking documentation issues. Thus, a documentation issue tracker has been proposed by the Docs team.
Goals
The documentation issue tracker has two main goals:
- easy reporting of issues throughout the project to Docs team
- easy tracking of reported issues
A successful documentation issue tracker ultimately will improve documentation throughout the project.
Stakeholders
The docs team is the major stakeholder for this project, given they will be primarily using the tracker.
An owner is needed.
@samuelsidler will project manage and work with the docs team and owner.
Solutions
There are two major features to a documentation issue tracker:
- reporting interface
- tracking interface
To ensure we complete our goals, we’ll use the following metrics:
- user tests of end users reporting documentation issue (to ensure it’s easy)
- feedback from Docs team for tracking
Components
As stated above, there are two components to the documentation issue tracker: Reporting and Tracking.
Reporting
For the reporting interface, we need to do the following things:
- determine where this reporting interface will exist (only on a specific page or a link everywhere?)
- if the latter, we may need a second design
- identify what information needs to be collected for each report
- determine who can report issues (e.g., do they need to be logged in?)
- design an easy-to-use interface for reporting
- build a reporting interface
Next Steps:
- work with the Docs team on steps 1 through 3
- assign/find a designer to create the reporting interface
- work with developer to determine backend for reporting interface based on requirements
Tracking
The tracking interface will be used mostly by the Docs team to track incoming and active issues. Part of this interface involves viewing issues individually and changing their status. Editors (or Gardeners) will need specific permissions to make actions.
To this end, there are a number of things we need to consider:
- determine what information is important to display on the tracking interface
- determine what user roles will exist and what permissions they will have
- investigate what other information may be required by editors/gardeners
- design an easy-to-use tracking interface
- design an easy to use issue-viewing/editing interface
Next Steps:
- work with Docs team on steps 1-3
- assign/find a designer to design the tracking and issue-viewing/editing interface
- work with developer to determine backend for reporting interface based on requirements
Note: As it stands right now, this issue tracker will likely have a one-size-fits all tracking interface and not allow much customization as far as tracking. However, we will want to allow sorting by “component”.
Eric, 
Jen Mylo
Trac Notifications
A lot of people are confused about how to sign up to get notified of trac ticket activity. To help someone I just spent ten minutes looking around for good instructions (note: add to core contrib handbook in part about trac).
Is there any way to pre-fill the trac preferences tab for name and email with the information stored in the user’s wordpress.org profile?
-
Sergey Biryukov
-
Kim Parsell
@jenmylo, I’ve added the instructions on how to set email preferences in Trac to the Opening A Ticket tutorial in the Core Contributor Handbook: http://make.wordpress.org/core/handbook/working-with-trac/opening-a-ticket/#getting-started
andreamiddleton
Today I imported all make.wordpress.org/events posts to make.wordpress.org/community. This resulted in three unexpected results.
1.) I chose to import users from /events, but those users don’t seem to have been imported. (I added heatheracton and adavis3105 as a test for the second issue.)
2.) Comments made by authors on /events are now showing my Gravatar and, when you click on their names, connect to my wporg profile. For example, Heather Acton’s comment here. A close up: http://cl.ly/image/2d05343x101V
3.) There seems to be a character encoding issue on imported content: http://cl.ly/image/2q2I1D1d3q0t
Help me, meta team, you’re my only hope.
-
David Laietta
Hi Andrea, did you have to split the XML file into multiples? I’ve gotten issues importing authors before when that has happened. Also depends if there is a lot of media making the file larger. I’ve had several issues with the importer, and I see that it’s not a single issue:
http://www.wptavern.com/whats-going-on-with-the-wordpress-importer
Dunno how /community is being set up, but can the proper tables from the DB be imported directly, then cleaned as needed?
-
Andrew Nacin
All of this content will need to be deleted from /community and re-imported using the special WordPress.org importer.
We’ve seen these encoding issues before on import and I don’t actually know what is going on, but we need to figure it out.
Can we delete the imported /events content from /community and hold off on the merge until I can sit down and do this later this week? Also so I can properly shut down and redirect /events.
-
Samuel Wood (Otto)
Oof.. Yeah, kinda wish you had not done that. Still, it’s only 81 posts, so we can delete them without too much effort.
I’ll look into the encoding issues. Nacin has disabled importing on the make sites to prevent this sort of accident in the future. We’ll figure it out.
-
Samuel Wood (Otto)
Okay, I manually deleted the posts on /community to remove these bad imports. I’ve left them in trash for the moment though, so if I was overzealous in my deletes then we can get them back.
Meantime, I also grabbed a copy of the export from /events and will look at the encoding issues on the importer. Character sets are annoying.
-
C�tia Kitahara
I don’t know if you have already looked at the encoding issues, but the problem is still there.
-
Ian Dunn
Open Sourcing Meta Plugins
TL;DR: I’m proposing that some of the new plugins we write for WordPress.org live in the official plugin repo, rather than the Meta repo.
I’m working on #meta187 and part of it is a modification to P2 to allow assigning a category to a new post. I created a plugin for it, and initially I was just planning on putting it in the Meta SVN repo, but since this is generic functionality — rather than something specific to WordPress.org — I started thinking about where the best place for it to live would be.
One of our goals it to open-source as much of WordPress.org as possible, and putting the plugin in the Meta repo would achieve that, but probably not in the most effective way. 99% of WP users and plugin developers aren’t aware that the Meta repo exists, so the code isn’t very visible. And if they wanted to get updates, they’d have to set it up as an svn:external, rather than just using the regular plugin update system.
So for the most part, the only people who would benefit from using it outside WordPress.org, or contribute back to it, would be other developers on the Meta team.
So instead, I’m thinking we should put it — and other plugins like it, in the future — into the regular WordPress.org plugin repository. That would give it much more exposure and would make it easy for others to use the plugin. The extra exposure would lead to more feedback from users and more contributions from developers.
We could add the wordpressdotorg user as a contributor to the plugin, to ensure the Meta team still has commit access to it if the original developer isn’t available.
What does everyone think about that?
-
Ian Dunn
One potential problem would be providing support for the plugins. We obviously don’t have the resources to do that for other users, which could lead to frustration on both sides.
I think if we could mitigate that problem by putting a note in the plugin description on the repo, though, letting users know up front that we’ll only support bug fixes and security issues, but won’t provide any support for helping them use or customize the plugin.
-
David Laietta
I think that it’s a great idea to put it somewhere public and usable. While leaving a note about support might also be a good idea, you’re probably still going to end up with some users expecting it. Hopefully the niche needs of the plugin will make this less likely to happen.
-
Ian Dunn
Yeah, I think you’re right that we’d still get some people expecting it. As long we do our part to manage expectations up front, though, I don’t think I’ll feel bad about ignoring the requests. It’s also possible that other forum users will be able to help them out, too.
-
-
Ulrich
Has GitHub been thought about? That would make it easier for other developers to provide improvements.
-
Ian Dunn
There have been a lot of discussions about GitHub vs the WPORG repo in the larger community, and I think the general consensus is that we’d rather use and improve our own tools, rather than rely on a third party. The WPORG platform includes parallels for a lot of GitHub’s features, although I agree that they’re not as nice as GitHub’s right now. We can always use both, too, but then that involves extra work to keep them in sync and manage multiple forums, bug trackers, etc.
-
-
Erlend Sogge Heggen
Would love to have easier access to the various Meta customizations. Love the idea!
-
Andrew Nacin
For this particular situation: Unfortunately pretty much any plugin written for P2 is a terrible hack that is always very fragile and can very easily break. (I can see how fragile and hacky this one is from the screenshots.) Despite writing a dozen plugins for P2, I will never release a plugin for P2 into the directory and I don’t think anyone should. Also, with Automattic finally writing a replacement, we will likely be able to replace it next year sometime.
More generally: The meta directory is designed to be a place for code that powers WordPress.org, not a place for people to install code from for their own site, in the same way they would a plugin. It’s purposely designed to not target 99% of users. If someone wants to run it on their own site, they’re welcome to (and it’s all GPLv2 or later), but it isn’t something that we need to be encouraging.
Are there some things that could be useful in the plugin directory? Perhaps. But we’re not writing code for mass use or mass support, we’re writing code specific to WordPress.org in order to make WordPress.org better. And that should be our focus.
If we write something that makes sense as a “mass-market” plugin instead of being checked into meta.svn, I think we’ll know it when we see it. Most of the plugins I have seen running on WordPress.org (many of which I wrote) are just a few adjustments using filters. When the handbooks plugin becomes more than a set of hacks and actually has a decent, matured feature set, I think it could be a fine plugin. For reasons stated above, I wouldn’t publish this particular plugin to the directory, but that decision is totally up to you.
-
Jen Mylo
I agree with @iandunn, that this instance is a general plugin not specific to the wordpress.org setup (I have had feature requests for it before from WC organizers and meetup groups, for example, who use P2). That said, if the wordpress.org team won’t support it and it’s just Ian writing it, then we could get around the “WordPress thinks this is worth releasing and supporting and building a community around” implication by having Ian release it in the repo with Automattic rather than .org as the author. Since p2 comes from Automattic also, and Ian is employed by Automattic, that wouldn’t be weird. Then .org would just be a user of it instead of an official party.
-
Ian Dunn
I released it at http://wordpress.org/plugins/p2-new-post-categories for others to use.
-
-
-
Bryan Petty
I tend to agree with @nacin here, and just have a couple other thoughts to add.
With everything running on WP.org actually managed and maintained on meta, it’s all in one spot where anyone who wants to contribute knows where to go rather than maintaining a secondary list of WP.org sites, and which plugins in the whole directory are installed and being used at any given time. Of course, this mostly echoes the notion that this is for WP.org, not anyone else.
I guess nacin already covered this as well, but it’s worth reiterating that a *lot* of these plugins are frequently going to be minor filters, adjustments, and system hooks very specific to WP.org, and those definitely are not going to be worth the trouble of listing individually on the plugins repo, so there’s already going to be stuff maintained in meta regardless. Might as well leave the rest there too unless it absolutely makes sense to publicly offer it as a usable plugin to the masses, and those can be handled on a case-by-case basis.
-
Sam Sidler
I also agree with @nacin and @bpetty. I don’t think this should be something we push for, but when it makes sense, if the plugin developer (in this case, you) wants to do so, they can. But even in that case, we’d still want to pull in the plugin from the meta svn and not the plugin directory.
-
Ian Dunn
Nah, I don’t think it’d be good to maintain two different copies. I’m fine w/ just using Meta for this since that’s what everyone else wants.
-
Mert Yazicioglu
Profiles – Weekly Update 12
As you know, I’m working on enhancing profiles.wordpress.org as a part of GSoC’13 and this is my twelfth weekly update regarding how things are going.
While Scott is working on deploying the new profiles to .org, I decided to complete the next week’s task, which was:
September 9th – Any necessary documentation should be written by now.
You can see the documentation here. Thought it might come in handy for the maintainers of these plugins and installations on .org
See you next week!
Ian Dunn 11:00 pm on October 7, 2013 Permalink | Log in to Reply
It’d probably be better to create a Trac ticket for this, and reference #116.
George Stephanis 11:38 pm on October 7, 2013 Permalink | Log in to Reply
Actually, it’s a CPT on the home site. Fixed.
Eric 12:39 am on October 8, 2013 Permalink | Log in to Reply
Much obliged