A Passionate View on All Things Bali

Varied of coconut trees being intensively develop in Bali. This development aimed to fulfill ritual necessity held by the people. The area for Coconut plantation itself had been expanded that reached around 66 hectares. 25.000 seeds supply had been planted on the rainy season of December last year. That extension conducted at every public land, temples’ land as well as both sides of the street which also has greening plants function. Coconut expansion and intensification receive full support from local budgetary and expense as well as from self-supporting farmers. Read more about Coconut development in Bali here.

A Report from the 3.0 Development Cycle

Menus

There’s been a flurry of blog posts about the integration of the WooThemes Custom Navigation into WordPress core, so I thought it was time we posted the official word. For 3.0, the main user-facing feature we wanted to include was a better site menu management system. Currently, dealing with menus is clunky, using Page IDs or in some cases categories, if a theme uses categories instead of pages for the menu. We wanted a menu system that had the drag and drop ease of the widget management screen, could combine Pages, Categories, and Links, was able to be re-ordered, allowed submenus, and enabled hiding specific Pages or Categories from the menu altogether. We were in the process of building this when WooThemes introduced their Custom Navigation system. Watching their introductory video, it seemed that their system did pretty much everything we wanted to do for core, so we reached out to them about contributing to core.

As you’ve probably heard, it worked out, and the first patch has been submitted. It does require some code modification, which is happening now. The decision to incorporate the Woo menus happened right before our planned feature freeze for the 3.0 development cycle, so we pushed our freeze date back by two weeks to allow the addition. We’re now targeting the 3.0 release for early May, and we think it will be worth the extra two-week wait.

I’m personally really happy that it worked out this way, because I think it will show commercial theme and plugin authors that contributing to core is a win-win proposition. More people can contribute to and improve the basic functional code now, while WooThemes can continue to innovate on top of it for their customers. They get massive bragging rights (which I have no doubt will lead to even more customers), core gets a nice menu system without having to reinvent the wheel, and WordPress users all over the world will benefit. I’m hoping other plugin and theme developers will take a cue from Woo and look at core as a place for collaboration, rather than competition.

The Merge

It was announced at WordCamp San Francisco last year that WordPress and WordPress MU would be merging codebases. This has now happened in 3.0-alpha, and we’re working on smashing bugs and tidying up a few screens. If you’re currently using a single install of WordPress, when you upgrade to 3.0 you won’t see any of the extra screens associated with running a network of sites. If you’re currently running MU, when you upgrade you’ll notice a few labels changing, but upgrading should be as painless as usual. If you’re going to set up a new WordPress installation, you’ll be asked as part of the setup if you want one site or multiple sites, so that’s pretty simple. If you want to turn your single install into one that supports multiple sites, we’ll have a tool for you to use to do that, too. So if you’ve been worried about the merge, have a cup of chamomile tea and relax; it will all be fine.

Patch Sprint!

Okay, so where are we now? The new feature freeze date is on Monday, March 1, 2010. That means that after that date, no more enhancements or features will be added, and we’ll switch gears to focus solely on crushing bugs and fixing up the features that have already made it in. That means we only have a week to try and finish up the many Trac tickets on the 3.0 milestone that either need a patch or have a patch that needs testing. You can help! From now until noon eastern time on March 1 (that’s 17:00 UTC on March 1), head on over to Trac and pitch in. If you hit a wall, hop into the core development channel at #wordpress-dev on irc.freenode.net and hopefully one of the friendly core contributors can give you a push.

I like to moderate comments when I’m waiting for something: a checkout clerk to help me, the dentist to call me back to the office, a soy chai to be made. I don’t lug my laptop everywhere I go,* so I love it that we have mobile apps that make this possible. I don’t know of any other blogging platform that has mobile apps for iPhone, Android and Blackberry. Do you?

The iPhone app is up to version 2.2 (note that iPhone app version numbers do not correlate to WordPress core versions, due to separate dev cycles), while the Android and Blackberry apps are brand new. You can write posts (save drafts or publish right away), moderate comments, blog photos from your phone (and video on Blackberry!**), and more. Check out the glory that is mobile WordPress in the image below:

“But what about my Nokia,” you ask? Raanan Bar-Cohen, who oversees the mobile projects, recently announced:

“We are very excited to share with all of you that in the coming weeks we’ll be opening up a beta test for the official Open Source WordPress for Nokia app. For developers who are interested in getting involved, we just opened up a dev blog with details, links to the source code and trac tickets, and an early alpha build. We’ll be leveraging the Qt framework which means will be able to support both the S60 and Maemo platforms.”

W00t!

Getting Involved

All of these mobile WordPress apps are free and open source. They are developed in the same manner as WordPress core, which means anyone can contribute! If you’ve got some mad mobile development skills and want to get involved, a) you’re awesome, and b) here are a bunch of useful links.

Development Blogs: Android | BlackBerry | iPhone

Development Tracs: Android | Blackberry | iPhone

Feedback Forums: Android | BlackBerry | iPhone

Language Support: WordPress users come from all over the world. The mobile apps here are available in multiple languages but need volunteers to enable even more people to use them. If you’re interested in helping localize these mobile apps, you can get involved by emailing the translation team. They’ll send you instructions on how to translate.

Getting the Apps

So go for it — download the app for your platform of choice and soon you, too, can be live posting about how slow the cashier is while you wait for him to ring you up!

* Okay, yes, I do bring my laptop everywhere, but I leave it in the bag on these occasions.

** Video support should  be coming soon to the iPhone and Android apps.

Thanks to everyone who tested 2.9.1 Beta 1.  We’re following that up with Release Candidate 1.  RC1 contains a few more fixes, bringing the number of fixed tickets up to 23.  If you are already running Beta 1, visit Tools->Upgrade in your blog’s admin to get RC1.  You can also  download the RC1 package and install manually.  If all goes well, 2.9.1 will be here soon.

Merry Christmas! One of the things that was discussed at the core commit team meetup was release scope (and scope creep). Now that 2.9 is out and it’s time to start thinking about 3.0, we think it would be appropriate to stop and take a breath before diving in, and make a plan in advance. What winds up happening is that during each release cycle a few new features are selected for inclusion, but then right up until feature freeze (and/or beta cycle), people keep adding feature requests, patches for enhancements, and ongoing bug reports. This means each release winds up getting pushed out later than planned, and with so many things going in per release, it becomes harder to catch new bugs.

The as-long-as-we’re-not-in-freeze-yet model isn’t working. People wind up waiting months longer for new features they want, like Trash and Image Editing, because we’re still adding other things and then we need to test them all. If we kept the releases smaller feature-wise, we could push out the new stuff sooner (3 releases per year is the goal) and have more focused beta testing, making the releases themselves better. It’s hard, because everyone has their pet features and fixes, and if there’s a patch, why not get it in this release rather than waiting? Sometimes people complain that a patch has been waiting to be committed for weeks or months, but what no one ever seems to bring up is that sometimes patches introduce new bugs, and the more we add at once, the harder it is to keep it all well-tested on various platforms, in different hosting environments, etc. So. What’s our proposal?

We take a page from the world of project management and we make a project plan before we jump into the dev cycle. We let everyone propose features and enhancements, and we choose a limited number to include in 3.0 (in this case we need to be especially stringent, because the merge of WordPress and WordPress MU will automatically mean a lot of work) and set a realistic release date that we stick to. We create a tentative set of features for the next two releases, to be re-evaluated at the beginning of the next cycle, so that people know the community is committed to certain features, as opposed to the vague “future release” label we now use for everything not included in the current version. We fix bugs that are reproducible and affect a large number of users before focusing on edge case bugs or bugs that haven’t been well-described or reproduced. We stop diverting our attention from agreed-upon goals when a “squeaky wheel” decides we should all be focused on something else. There are always things that pop up unexpectedly, but we need to do a better job of restraining ourselves when it comes to trying to sneak things into the current release (I include myself in this, of course…as a UX person I always wish we could do everything all at once!).

As an open source project, we accomplish more when we work together than we do following individual agendas, and we need to keep our project focused on commonly-agreed-upon goals instead of following tangents whenever a community member starts to take us on one, regardless of whether it’s to follow a cool idea that everyone loves or a suggestion based on a personal agenda, and regardless of whether it’s a newbie who doesn’t know any better or a frequent contributor or committer who has a strong opinion and a loud voice (so to speak). The issue here is that it’s easy to get distracted, so we need to create a structure that will help us keep moving forward instead of getting sidetracked. We need to keep Trac clean for the current dev cycle so that it includes confirmed features and bug reports, and all new feature suggestions go into a different milestone.

We think it’s at least worth a try. When we re-start the weekly IRC dev chats in 2010, the first meeting will be to talk about the scope of 3.0. When we’ve got a general agreement about what will be included, we’ll create the appropriate Trac tickets, and punt tickets for non-3.0 feature requests/enhancements to a future release so we can stay focused. New bug reports will still come in to the current milestone. It’s going to be hard. There are at least a dozen new features that I feel like we’ve pushed back multiple times that I’d like to see in core, but for this experiment, I’m just going to keep reminding myself, “You can do that with a plugin!”

Sound off on the features you would like to see in version 3.0.

After the video from the core team meetup was posted, the topic that seemed to get the most attention on Twitter and various community sites was Matt’s announcement that there would be a new default theme in 2010, so I thought I’d start with that as the first of the meetup summaries.

When Kubrick was bundled with core back in 2005, it was a cutting edge theme. Custom header, rounded corners, clean design… if you were using WordPress back then, let’s face it, you were impressed. Time moves on, though, fashions change, new styles become old standards, and what was once cutting edge suddenly seems old-fashioned and out of date.

So, a new bundled theme in 2010? We think it’s a good idea. Something nice and light that can serve as a good example theme, include newer theme-based features, and look nice (and current) on a public site. We’d like to introduce a new default theme with version 3.0, which is anticipated to come out in mid-2010 (hence the name), and think it would be good for it to blend well aesthetically with WordPress itself.

I’d been advocating moving toward Elastic, the theme framework/WYSIWYG theme editor that was one of our Google Summer of Code student projects, but after some discussion I agreed with the guys that while Elastic is awesome and should be promoted as a community development project, it’s heavier than a default theme needs to be. The default theme doesn’t need to be a full-featured framework, it just needs to work well, look awesome, have good code and be a good starting point for beginning themers. We were thinking of a fairly minimalist design that would make it easy to customize.

As for the code, there’s a question of if it will really be a new theme, or if it will be a re-styled and updated version of Kubrick.  We don’t know the final answer to that yet, because the ultimate decision will be made with the community’s input, but we believe all new markup is the way to go. What do you think? Without venturing into theme framework territory, are there features you think a new default theme should have? Some people have been talking about it on Trac over the past year, if you wonder what’s been tossed around so far. I thought about posting a poll here (you know how I love posting polls to gauge opinion), but in this case I think a discussion thread might be better, so that each vote can explain the reason behind it. So, have an opinion on what a new default theme should include? Weigh in at the forums.

We’re at that exciting point in WordPress development where the dev team feels like version 2.9 is complete and ready for the world.

If you’ve been waiting for your moment to pitch in, it’s now. First we need tech savvy testers to upgrade their blogs and kick the tires, make sure everything is rolling like you expect it to. Here’s a list of all the fun and geeky new stuff in 2.9 to try out. Second, and more importantly, we need everyone to test out their plugin compatibility.

If you’re a user of plugins, there’s a groovy new compatibility feature on the plugin directory where you can vote on whether a plugin is compatible with a version or not and it’ll get registered in the new plugin compatibility checker. This is as a replacement to the old wiki-based lists we’d do before. To see it in action check out this Akismet plugin page, as you can see 14 people have already registered that it’s compatible with 2.9.

If you’re a plugin author, of course you should update your “Tested up to:” in the readme.txt for your plugin.

If all goes according to plan, WordPress 2.9 will be out before the end of the week. You can download the release candidate here.

For more details on the changes since Beta please review the revision log on Trac, and happy testing!

To get started, here’s a short video from the meetup discussing some of the topics and 2.9. In the opening pan, you’ll see (L-R) Andrew Ozz, Mark Jaquith, Jane Wells, Peter Westwood, and Ryan Boren, followed by Matt Mullenweg as the first person talking. Tip: go full-screen in HD to feel like you were there.

Last week, I posted about the fact that Trac would be quiet for a few days while the core commit team met in person for the first time to talk about some goals for WordPress in the coming year. That prediction wound up being a little inaccurate, as having everyone together inspired a Trac sprint to get us closer to shipping 2.9. As of this morning there are only 11 tickets left against the 2.9 milestone. Yay! I’m sensing a Release Candidate in the near future.

I’d planned to write a summary post to encapsulate the discussions we had over our 3 day meetup, but to be honest, all-day (and night) every-day meetings creates a ton of things to summarize, and the post would be a novella. So instead of one long post, I’m going to split it up into a series and post a summary of the discussion on one or two topics per day until I’ve posted them all. Think of it like a WordPress advent calendar. For today’s post, enjoy the video above and I’ll list the topics we covered to give you an idea of what will be included in the upcoming summary posts.

Topics: Direction for the coming year(s), canonical plugins, social i18n for plugins, plugin salvage (like UDRP for abandoned plugins), WordPress/MU merge, default themes, CMS functionality (custom taxonomies, types, statuses, queries), cross-content taxonomy, media functions and UI, community “levels” based on activity, defining scope of releases, site menu management, communications within the community, lessons learned from past releases, mentorship programs, Trac issues, wordpress.org redesign, documentation, community code of conduct.

You can see why I didn’t want to try to cram it all into one post, right?

Just to make sure it’s clear in everyone’s minds, I want to reiterate that these discussions were just that: discussions. They were not secret meetings ending in hard and fast decisions. The idea was to 1) get the core commit team on the same page in order to improve workflow efficiency and communication, and 2) come out of the meetup with a long list of things we know we want to work on in the coming year, and from there to work with the broader community to determine priorities/strategies before starting the work of getting it all done. As I finish off 2009 by posting summaries of the meetup conversations, I hope you’ll all plan to start 2010 with enthusiastic participation in one or more of the projects that will take these conservations from concept to reality.