Jen 10:23 pm on July 1, 2009
Tags: process ( 4 )

Starting next week, we’ll be attempting…

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).

#process

Jane Wells 10:24 pm on July 1, 2009

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
  
  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
    
    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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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
    
    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
    
    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
    
    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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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
    
    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
    
    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

bugs, bugs, bugs, bugs. there are too many in tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., 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
  
  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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., 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
    
    > 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., 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
  
  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 tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..
  - Xavier 10:39 pm on July 2, 2009
    
    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, coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-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
    
    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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. wranglers; but at the end of the day, if the final patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. (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
    
    @xavier: Indeed, but sometimes, you notice that a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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 filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. 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 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. that follows.
  - Andrew Ozz 10:43 pm on July 5, 2009
    
    Not exactly. Widgets support was introduced in WordPress 2.2 by adding the then very popular SidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. Widgets pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. 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 patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.-fixes. Still see quite a few tickets in tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. marked as tested, commit, highest, blockerblocker A bug which is so severe that it blocks a release., 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
    
    “Also, my old timers have learned better and no longer upgrade to a new major version of WP before the first minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. 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
    
    @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 wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. wrangler, whose only feedback from potential committers is that his patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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
    
    @Denis: The thing is that for an end-user it is new features that drive the upgrade cycle not bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes. If we don’t have any new features there is no point in doing a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope..
    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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party work. I am all for adding filters and hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. 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
    
    @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 tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 ticketticket Created for both bug reports and feature development on the bug tracker.. As the number of tickets is gargantuan, a significant number of them end up ignored even with a perfectly valid patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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
    
    @Denis: We get it. You think the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and reply to tickets (even if it’s just a boilerplate, “Checked this patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., needs more testing”), we can’t fix every single issue with the open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. 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
  
  Just because there are a lot of bugs in tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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
    
    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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. and/or patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., and they end up moving on.
Jeff Waugh 6:21 pm on July 3, 2009

A fairly minor enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. suggestion for 2.9, with patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.… prettier (Tango style) smilies in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.:

https://core.trac.wordpress.org/ticket/10145

Thanks. 🙂
- Jane Wells 3:30 pm on July 7, 2009
  
  Committed to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., so not on agenda for this Wednesday. 🙂
- Lloyd Budd 4:24 pm on July 7, 2009
  
  Jeff, some interesting feedback from wp.com users http://en.forums.wordpress.com/topic/new-smilies
  - Jeffro 10:44 pm on July 10, 2009
    
    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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but at least with the visual elements that are seen by many people, I would think this would merit such a case.

Comments are closed.

Welcome!

Communication

Starting next week, we’ll be attempting…

Welcome!

Communication

Share this: