Starting next week, we’ll be attempting to follow an agenda during the Wednesday dev chats. If you would like to propose a topic for the July 8, 2009 dev chat, please submit it in the replies/comments to this post. We’ll post an agenda the morning of the dev chat (i.e., about 8-10 hours in advance).
Jane Wells 10:24 pm on July 1, 2009 Permalink |
I will want to discuss the rankings from the feature poll that we’ll have up by then. It will still be running, but we should have a few days’ worth of votes, which is when we get the bulk of them anyway.
Denis de Bernardy 10:29 pm on July 1, 2009 Permalink |
If I may, it’s going to be much more important to find the volunteers to code the stuff.
Jane Wells 10:56 pm on July 1, 2009 Permalink
True, but we can’t very well assign volunteers to specific feature development if we don’t know the features, and we don’t want to decide features without community input (as opposed to the core devs and or just the dev chat making these decisions). So while finding volunteers is super important and definitely harder than deciding features, we do need to decide the features as well.
Denis de Bernardy 7:35 am on July 2, 2009 Permalink
Indeed, but at the end of the day I tend to remain very down to earth on this kind of thing.
End-user feedback is meaningless if nobody shows up to code their requested features. On the contrary, asking for such feedback can have a negative impact. If those who are coding patches ignore the feature requests and prefer to focus on other things, you end up in a situation where users go “WP Devs ignore their community’s input”.
Thus, please make sure someone’s willing to code feature A, B, C before submitting it to any kind of vote.
DD32 8:35 am on July 2, 2009 Permalink
Voting is the only way to do it.
Those who vote are those who’ll contribute, If you vote for a feature, Be willing to put the effort in for getting it in.
In previous votes, Those which no-one is interested in coding(Even if there was a huge community want for) will receive little interest. Thats how it works around here. Yes, You might think this is a “wp devs ignore users” but in reality, Those who are contributing are not payed by the community to do so, Features are implemented when someone with the passion for it comes along and says “I want to do this”.
Jane Wells 2:12 pm on July 2, 2009 Permalink
That point of view is in direct opposition to the idea of letting the full community have input into our feature set. Worst case scenario is that the core devs code features no one volunteers for and it takes longer, so knowing the priorities of the broader community is imperative in deciding which features they should focus on first.
As with every vote, we make it clear that the vote is to influence core decisions, not to make them, so your argument does not convince me that we should forego voting before assigning developers to features. There’s no point in coding something that isn’t important to the broader community, and we aren’t going to put features in core just because a developer offered to code it, if it’s not to the benefit of the wider community.
Community opinion + technical considerations + developer availability = How core decisions get made. We need all three factors to make a decision.
Matt 4:30 pm on July 2, 2009 Permalink
If something is important and worthwhile, we’ll get it done.
Sometimes that means working on un-fun things but that’s okay.
Peter Westwood 7:22 am on July 3, 2009 Permalink
There is no point coding features that people don’t want just because someone wants to code them – that is just adding bloat
We need to know what the community desires so that we can focus on the right things.
Denis de Bernardy 10:28 pm on July 1, 2009 Permalink |
bugs, bugs, bugs, bugs. there are too many in trac, they need to get fixed/addressed, and there are bottlenecks to getting them tested and fixed. I stand by my opinion on this. the short short version is: need… more… committers…
DD32 8:45 am on July 2, 2009 Permalink |
You’re right, Less tickets would be nice. But its not going to happen by clicking fingers. Nor is it going to happen by more commiters.
Like you say, There’s bottlenecks to getting them tested, But having more commitors will not help push it along, And it has the possibility of introducing more bugs. Currently there are 46 tickets marked as tested, I’ve just glanced over the “tested” tickets, and in my opinion, over a dozen are not commit worthy(By my standards), Not in the best interest of WordPress or Not really something that needs “fixing” (ie. not really a bug, just not working the way most expect). Those are the major reasons why tickets marked as tested do not get commited.
There is a line that has to be drawn sometimes about what should be added to WordPress now, and what needs to sit and mature a bit first.
DD32 8:46 am on July 2, 2009 Permalink
> Nor is it going to happen by more commiters.
By that i mean, Nor will it happen by more “decent” commitors who can tell the difference between a good patch, and a bad patch. Adding 20 commitors will certainly get the current patch list down, but i wouldnt want to be the one cleaning up the mess.
Matt 4:30 pm on July 2, 2009 Permalink |
We need to be careful as we go through tickets — I feel like a blind chasing of low-priority bugs in the last dev cycle delayed the release and the resulting changes introduced instability we haven’t had in a few releases, regardless of the arbitrary metric of # of tickets in trac.
Xavier 10:39 pm on July 2, 2009 Permalink
True enough. In my 2.8-presenting post on WPFR, I came out hoping that the sheer number of tickets solved was proof that 2.8 was among the cleanest and most stable release since a long time. Turns out that’s wrong, since 2.8.1 comes with a bunch of bugs that (AFAICT) should have been spotted earlier.
While I can’t be against more committers, I’d be also in strong favor of asking for more tests, insisting the original reporter (and participants to the tickets) to make sure an issue is indeed fixed without side-effect, and maybe build more automated & user tests?
Insisting on community leaders to have their staff and community make real-world tests of betas and RCs (with according test plan sheet, even?) ? I’m afraid a lot of us tend to rely on the “hey, core-devs are good, no need to worry. oh shoot, that feature is b0rked. bah, they’ll prolly know about it, it’ll get fixed eventually”.
Typing while thinking, not sure that’s legible. Short version: moar testing.
Denis de Bernardy 8:20 pm on July 4, 2009 Permalink
I partially disagree. The issues that introduced major bugs in 2.8 were, best I’m aware, related to enhancements. What would have been needed then would have been 2-3 more weeks of testing. Or as you like to put things, more testers during the test period we got — the end result being the same thing.
Either way, it goes down to keeping the contributors interested. The surest way to make them so is to when they quickly get feedback and/or supervision from someone who can end up committing. As things stand, there oftentimes is a second opinion from bug wranglers; but at the end of the day, if the final patch (on which everyone who contributed and expressed an opinion is happy) ends up stale because committers had better things to do, we end up generating frustration (and losing contributors/testers).
Denis de Bernardy 8:40 pm on July 4, 2009 Permalink
@xavier: Indeed, but sometimes, you notice that a patch broke things long after it occurs. #10300 is typical of this. We introduced a WP_Widgets class in 2.8, and added an extra patch in 2.8.1 that makes is_active_sidebar() use wp_get_sidebar_widgets() so that a filter gets used. We ended up with a fully broken upgrader for pre-2.2 sites that were using widgets — but you’d only ever notice if you actually verify that your upgrade scripts still work, and the odds are slim that you would until it’s too late.
As for “insisting on community leaders to have their staff and community make real-world tests of betas and RCs”, I’m pretty sure they all do. FWIW, though, my own beta for the 2.8 WP occurred when 2.8.1 was already in beta. Also, my old timers have learned better and no longer upgrade to a new major version of WP before the first minor release that follows.
Andrew Ozz 10:43 pm on July 5, 2009 Permalink
Not exactly. Widgets support was introduced in WordPress 2.2 by adding the then very popular Sidebar Widgets plugin to core. As part of that a function was introduced to help the users of this particular plugin by converting their old settings for use with the new core functionality as the plugin couldn’t be used any more. Unfortunately in some rare cases this conversion was interfering with another conversion needed for WordPress 2.8, changing the default widgets settings from single to multi-instance format.
The upgrade from WordPress <= 2.1 to 2.8 is working properly regardless of the patch in #10300 as long as all plugins are disabled during it which is the recommended way of upgrading. Of course the user would have to visit the widgets screen and possibly refresh some of the settings as many widgets have changed quite a bit too. The same is true for the rest of the WordPress settings.
Re: minor bug-fixes. Still see quite a few tickets in trac marked as tested, commit, highest, blocker, etc. that fix something small but introduce another problem or needless overhead. Some even add regressions. I understand that in some cases it's easier to change the core to make a particular plugin work but does that warrant pushing these changes to millions of users when they would only be needed by several hundreds and possibly breaking other plugins in the process?
Matt 4:17 am on July 6, 2009 Permalink
“Also, my old timers have learned better and no longer upgrade to a new major version of WP before the first minor release that follows.”
That perception of our releases horribly toxic, and exactly what we’re trying to avoid. (And did with 2.7.) It’ll take a while to earn back trust, though.
Denis de Bernardy 3:20 pm on July 6, 2009 Permalink
@Andrew: I’ll take your word for it regarding the patches that introduce problems etc. But if so, these tickets should be explicitly marked as such, occasionally closed as wontfix if we actually don’t want to fix the thing. In short, they need some kind of feedback. Currently, the patches stand there with no feedback, and that gives a devastating impression. Picture a new potential bug wrangler, whose only feedback from potential committers is that his patch become stale after a few months? It just makes no sense. Fixing this very point should, imo, get a higher priority than adding any kind of feature.
Peter Westwood 9:37 pm on July 6, 2009 Permalink
@Denis: The thing is that for an end-user it is new features that drive the upgrade cycle not bug fixes. If we don’t have any new features there is no point in doing a major release.
Each release should get a dose of bug fixes, but as Andrew says we need to avoid introducing regressions or just doing things to make a plugin work. I am all for adding filters and hooks to allow plugins to be created but very much against doing things in the wrong way just because it makes a plugin work.
Denis de Bernardy 6:38 am on July 7, 2009 Permalink
@Peter: The key point I’d like to make isn’t that we should fix each and every on of them — even though I’d find this very desirable. Rather, it is that these bugs and many other tasks in trac are getting the attention they deserve. The key issue is we lack traction, and we do so for several reasons:
On the one hand side, we’ve bug wranglers, a dozen or so of which might qualify as regulars. They open tickets, write patches, test and review patches by others… On the one hand side, we’ve a tiny number of core devs with commit access who, at the end of the day, are the only ones who can arbitrate.
With only 2 core devs on a full time basis, and 2 on a part time basis, there is only so much time that they allocate to each ticket. As the number of tickets is gargantuan, a significant number of them end up ignored even with a perfectly valid patch creeps up.
The issue goes down to how the core devs manage their time and that of others.
I think everyone is fine with the idea that committers want patches reviewed by regular bug wranglers. It’s a perfectly valid idea: newbie wrangler shows up, reports a bug, offers a patch, awaits feedback, regular bug wrangler tutors him into writing a better one that he things can make it in core.
Then what? The ticket gets marked as needing dev attention in trac. But as core devs are busy worrying about their own todo lists, that ticket gets no feedback or attention. Sure enough, it’s stale a few weeks later, and the ticket ends up rotting in trac for months. The newbie wrangler left in disgust, and he’s right. Time helping, the regular bug wrangler feels discouraged.
How about inverting the core dev’s priority list, for a change? Instead of going through their todo lists first, go through what others are doing first. Close tickets we don’t want fixed. Express reserves about patches when there is a doubt on this or that point. Reject patch with similar feedback. Commit the patches that are worthy of committing.
In short, their highest priority item should be to keep the wranglers interested, and to work as a team with them.
Picture a software project manager who does every mistake in the book: not only does he allocates part of the work to himself, he distributes bit size tasks to his staff and allocates 99% of the work to himself.
In the above sentence, read software project manager as core dev, and staff as volunteer bug wranglers. It’s exactly the situation WP is in. You’ve a potential army of contributors out there. Use it.
Jane Wells 12:35 pm on July 8, 2009 Permalink
@Denis: We get it. You think the core devs don’t do enough, or at least you think they don’t do things in the right order. (For the number of hours they work, they are definitely doing more than the average person.) While I agree that the experience for new contributors is not optimal and could be improved, including perhaps scheduling specific times when each core dev would sift through Trac and reply to tickets (even if it’s just a boilerplate, “Checked this patch, needs more testing”), we can’t fix every single issue with the open source project’s organization at once. For today’s meeting, we’re going to focus on the 2.9 feature implementation stuff we agreed should be our focus when we spoke last week. The issue of the way the core devs handle Trac is bigger and would require more time. Also, Ryan will likely not be at today’s meeting, so talking about this would not be the best use of everyone’s time, since the discussion would just need to be repeated.
The core devs are not the only ones who could do better. I’ve noticed a lot of tickets being marked as “tested” or “commit” by one person with absolutely no information about what environments they were tested with, and no confirmation by additional testers. This kind of marking slows things down. *Everyone* should be leaving more information/comments in Trac, not just the core devs, to prove something has been adequately tested (and not just on one person’s dev environment) before it should be considered for commit status.
Peter Westwood 7:20 am on July 3, 2009 Permalink |
Just because there are a lot of bugs in trac does not make the software very buggy.
We need to hit the big issues and deal with some of them each release.
Any attempt to “fix” all the bugs in trac in one release cycle would just make things worse.
I don’t see that adding a huge chunk of committers improves anything.
We need a small number of good well tested patches which hit the big bugs.
A slower more heavily tested and reviewed development process produces more stable software than one where you just chuck all the fixes in you can find and hope they work.
Getting more people involved in things like automated test writing would be a big help – this means we can get good validation on the functionality at a low level which we are building upon
Denis de Bernardy 8:45 pm on July 4, 2009 Permalink
Nonetheless, reviewing and applying patches that fix bugs, rather than enhancements, should be much higher on the committers’ priority list imo. The end-result would be that the occasional contributor feels gratified and ends up contributing new patches. As things currently are, the odds are that many get the impression there is no real interest in their bug and/or patch, and they end up moving on.
Jeff Waugh 6:21 pm on July 3, 2009 Permalink |
A fairly minor enhancement suggestion for 2.9, with patch… prettier (Tango style) smilies in core:
http://core.trac.wordpress.org/ticket/10145
Thanks.
Jane Wells 3:30 pm on July 7, 2009 Permalink |
Committed to core, so not on agenda for this Wednesday.
Lloyd Budd 4:24 pm on July 7, 2009 Permalink |
Jeff, some interesting feedback from wp.com users http://en.forums.wordpress.com/topic/new-smilies
Jeffro 10:44 pm on July 10, 2009 Permalink
A little more than interesting. Although I’d say the feedback regarding the change is negative from a vocal minority, I’m in line with the suggestion that this is one of those things that definitely could have had the opinion of the community. In fact, I think a much better idea would have been to put the call out to redesign a new smiley pack for WordPress like they did for the icons in WordPress 2.7 while also providing an easy way to swipe out smilies with a new pack unless of course that has always been plugin territory. The bottom line is, you make a sudden change like this that is strikingly visual, you’re going to upset a lot of people. I know this can’t be done for everything that goes into core, but at least with the visual elements that are seen by many people, I would think this would merit such a case.