![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<?xml version="1.0" encoding="iso-8859-1"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <channel> <title>Poo-tee-weet</title> <link>http://pooteeweet.org</link> <description>Poo-tee-weet: ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life</description> <dc:language>en</dc:language> <generator>WebBuilder2</generator> <managingEditor>smith@pooteeweet.org (Lukas Kahwe Smith)</managingEditor> <webMaster>smith@pooteeweet.org (Lukas Kahwe Smith)</webMaster> <ttl>1440</ttl> <item> <title>Understanding what is wrong with meritocracy (part two)</title> <link>http://pooteeweet.org/blog/0/2301</link> <guid>http://pooteeweet.org/blog/0/2301</guid> <category>general</category> <description>Wow, quite a long time since I last wrote a blog post, which clearly hinted towards at least a part two one day. I recently started blogging elsewhere (more on that below) and kinda forgot about my old blog. Lately I have been getting spam on it though, which reminded me of this old post. So here comes part two. I should add that it didn't really take me 5 years to mature my thoughts on this topic, it just ended up that I communicated those thoughts in other places. </description> <content:encoded><p>Wow, quite a long time since I last wrote a <a href="https://pooteeweet.org/blog/2272">blog post</a>, which clearly hinted towards at least a part two one day. I recently started <a href="https://www.witty.works/post/being-good-guy-doesn-t-cut-it">blogging elsewhere</a> (more on that below) and kinda forgot about my old blog. Lately I have been getting spam on it though, which reminded me of this old post. So here comes part two. I should add that it didn't really take me 5 years to mature my thoughts on this topic, it just ended up that I communicated those thoughts in other places.</p> <p>That being said, one of the first learnings as I dove into this topic was that that step one was listening and learning. Basically I started expanding my twitter timeline to include more people specifically tweeting about the issues of diversity and inclusion. But also simply following more people with marginalized communities talking about tech.</p> <p>I paid attention to the dynamics in discussions. But one of the most clear ways I finally realized and fully accepted that <a href="https://twitter.com/jenistyping/status/1275279524784009219?s=21">meritocracy is a myth</a> came with this <a href="https://www.theguardian.com/technology/2016/feb/12/women-considered-better-coders-hide-gender-github">github study</a> that showed that while acceptance rates of PRs from women were well below those of men, the acceptance rate of PRs from women that hid their gender even slightly outpaced those of men.</p> <p>Due to this reality and the constant pins and needles on top of deliberate harassment, where keeping people from marginalized communities away and pushing those that made it out. We keep hearing about some pipeline problem but the real issue is that people from marginalized communities just see no point in staying. But obviously this is not the root cause. Just going from my personal experience at Liip, I can name more female developers that left IT than male, despite us having way more male developers. The good news here, better diversity is entirely possible in tech if we actually work hard on inclusion. This is why people say <a href="https://hbr.org/2014/06/diversity-is-useless-without-inclusivity">&quot;diversity is useless without inclusivity&quot;</a>.</p> <p>So with those realizations, I came across a tweet in the spring of 2017 by Erin pointing out the issues with an all white men speaker line up for a SymfonyLive event in the US. I first started rattling off excuses (note sure if just in my head or also in tweets), but eventually this finally gave me the kick I needed to become active. So I started reading more blog posts on the topic. Thanks to <a href="https://liip.ch">Liip's</a> education budget for all its employees, I ended up hiring <a href="https://otter.technology">Sage Sharp</a> to help me figure out the next steps Symfony should be taken and what pitfalls to avoid that could cause further harm.</p> <p>I was very happy to find that the Symfony core team was very receptive to this topic. Later that year we formally <a href="https://symfony.com/blog/the-diversity-initiative">launched the diversity initiative</a>. More importantly the community, aside from a few voices, was supportive as well and willing to learn and welcome change. We focused on several topics, like improving the language in our docs and on the website. We worked on guides for how to give and receive feedback in issues and PRs but more importantly we also worked on making those a lived reality. Quickly contributors started approaching the diversity initiative for support when they encountered situations where they felt overwhelmed. This helped deescalate a lot of situations but also helped train many contributors.</p> <p>We also implemented a <a href="https://opencollective.com/symfony-diversity-scholarship">diversity scholarship</a> to allow people from marginalized communities, that could otherwise not attend, to come and join us at SymfonyCon. One of the biggest successes was the adoption of a code of conduct, which lays the groundwork for safety as we hope to grow our diversity. More importantly, we worked in defining reporting processes and get the <a href="https://symfony.com/doc/current/contributing/code_of_conduct/care_team.html">CARE</a> (Code of Conduct Active Response Ensurers) trained by Sage Sharp so that they are prepared properly to enforce the code of conduct and sure reporters are properly protected and supported. Overall from the feedback I have seen we have made significant strides in improving our communication and openness. You can read more about this on the <a href="https://symfony.com/blog/category/diversity">Symfony blog</a>.</p> <p>That being said, all of this hasn't fixed our demographic issues within the Symfony community. There are still only men on the core team. While there are more visible figures within the Symfony community with a diverse background, we are still miles away from even just reaching the demographic representation of the proprietary software world, let alone the world in general. This is a long long path. What I do hope is that we do a better job at retaining people with diverse backgrounds within our community, which hopefully will also lead to more and more people with diverse backgrounds seeing us as a worthy community to invest their time. Potentially one important next step is trying to better understand the evolution of the demographics so that we can better assess if we are going into the right direction.</p> <p>In parallel I joined a startup called <a href="https://witty.works">Witty Works</a> last summer as co-founder that aims to improve diversity in the tech industry. Essentially the assumption is that since <a href="https://www.forbes.com/sites/shereeatcheson/2018/09/25/embracing-diversity-and-fostering-inclusion-is-good-for-your-business">diversity is good for business</a>, then there must be business for fostering diversity. Our focus is especially on dealing with unconscious bias and how to help companies address this head on, heavily involved by <a href="https://youtu.be/0KgevAOMHCA">Iris Bohnet's Book &quot;What Works&quot;</a>. Part of the strategy is to structure key processes to reduce bias and when possible automate this as much as possible so that we can bring the price to a point where mass adoption is possible.</p> <p>Our initial focus on the product side is the job ad. We built a tool called the <a href="https://diversifier.witty.works">Diversifier</a> that analyzes job ads in real time and suggests improvements along with explanations. This is based on research that shows that <a href="https://www.witty.works/post/language-matters-more-than-you-think">language</a> and other aspects of job ads deter applicants from marginalized communities. Our customers see a roughly 40% increase in applications from women. We hope to continuously build out more tools to cover the full application process and hopefully also more aspects of work life to foster diversity and inclusion. In the meantime we cover these topics via our <a href="https://www.witty.works/services">consulting services</a>.</p> <p>So what am I trying to communicate with this blog post? Back in 2015 I finally started to realize that I needed to educate myself on this topic and over the course of time I started to understand how I could become active in the open source and also in the professional world. I believe that as we see more and more people, especially white men who still hold on to so much power, choose to educate themselves we have an opportunity to improve things. It is however still a long long path, all the more reasons to act now. The good news is, the more people join, the easier it gets!</p> </content:encoded> <pubDate>Mon, 29 Jun 2020 17:51:24 +0200</pubDate> <dc:creator>Lukas Kahwe Smith</dc:creator> </item> <item> <title>Understanding what is wrong with meritocracy (part one)</title> <link>http://pooteeweet.org/blog/0/2272</link> <guid>http://pooteeweet.org/blog/0/2272</guid> <category>general</category> <description>Being fair is very important to me. I have however not really devoted my life to determining what the definition of fairness is, I mostly rely on my gut feeling here, like I assume most people do. In that sense I also accept that fairness, how most people apply it, is based on social conventions and personal experience. Both of which are not necessarily &quot;just&quot; in that social conventions often simply keep the ignorance of the past alive and personal experiences are essentially a social experiment with insufficient data. However I also assume that not leveraging social conventions or personal experience would make my daily life impossible as I would be overwhelmed with all the decision making. But if we choose to not challenge us in our daily life out of convenience, we should at least review our decision framework at regular times, especially by actively trying to expand our personal experience with the experiences of others. </description> <content:encoded><p>Being fair is very important to me. I have however not really devoted my life to determining what the definition of fairness is, I mostly rely on my gut feeling here, like I assume most people do. In that sense I also accept that fairness, how most people apply it, is based on social conventions and personal experience. Both of which are not necessarily &quot;just&quot; in that social conventions often simply keep the ignorance of the past alive and personal experiences are essentially a social experiment with insufficient data. However I also assume that not leveraging social conventions or personal experience would make my daily life impossible as I would be overwhelmed with all the decision making. But if we choose to not challenge us in our daily life out of convenience, we should at least review our decision framework at regular times, especially by actively trying to expand our personal experience with the experiences of others.</p> <p>Open source software development is without a doubt one of my big passions. What I enjoy most about it are three things: the intellectual exchanges, the intercultural collaboration and the empowerment it provides for people around the world. Especially in regards to &quot;intercultural&quot; the demographics in the open source world, especially in the western world, obviously do not represent the demographics in the real world and that of course diminishes on of the three aspects that attracted me to open source to begin with. Even if open source has enabled me to travel around the world both physically and virtually, I believe that the status quo is not ideal. In fact I also see this as unfair. Meaning its not just that it diminishes my enjoyment of participating in the open source world, I acknowledge that its an injustice that it seems that others are not getting an equal chance to at least enjoy the other positive aspects of open source development. So I would like to see this changed.</p> <p>Within my twitter timeline I see quite a few people linking to articles such as <a href="http://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community">&quot;The Ethics of Unpaid Labor and the OSS Community&quot;</a> and <a href="https://modelviewculture.com/pieces/the-dehumanizing-myth-of-the-meritocracy">&quot;The Dehumanizing Myth of the Meritocracy&quot;</a> that argue that meritocracy, the predominant decision structure in open source, is inherently flawed for two reasons: 1) merit isn't sufficiently objectively assessed to give marginalized groups equal opportunity and 2) that it perpetuates elitism and more specifically rationality over humanity. Now to me meritocracy isn't key to my enjoyment of open source directly but I have always held it as one of the key contributors to both the intellectual as well as the cultural exchange aspects. The statements in the linked articles put the fact if open source has truly achieved a cultural exchange into question and to some extend questions the motivation for the intellectual exchange as potentially wrong in and of itself. That is some pretty fundamental criticism of one of my biggest passions. Meaning it is very important to be able to address this and take necessary actions based on the expanded understanding I will hopefully gain.</p> <p>I will try to post about my findings. I assume that as I dive into this, I will say wrong things or more importantly I will say things where I have simply not yet understood the entire picture yet. I welcome criticism but I hope that people will refrain from attacking my character and instead address my particular statements. I have come to realize that the shortness of twitter messages often times make such differentiation impossible and as such discussions especially about this topic have gone of course from the original intention, i.e. they turned into insults or people pit opinions against each other needlessly resulting in defensiveness (which often results in counter attacks that spiral downward) rather than in an environment of safety required for a dialog about questioning fundamental aspects of ones passion. I will see if a blog serves as a better platform than twitter.</p> </content:encoded> <pubDate>Fri, 19 Jun 2015 11:09:37 +0200</pubDate> <dc:creator>Lukas Kahwe Smith</dc:creator> </item> <item> <title>The future of PHP .. at a distance</title> <link>http://pooteeweet.org/blog/0/2259</link> <guid>http://pooteeweet.org/blog/0/2259</guid> <category>general</category> <description>Its been quite a few years since I have been last subscribed to the internals mailing list. I still hang out in one of the popular core dev IRC channels, follow quite a few on twitter. So I still manage to stay on top of what is happening more or less but not the details in the discussions. Just wanted to put this as a disclaimer. Any opinions in this blog post are opinions formed watching something at a distance and this always runs the risk of being quite wrong or more impartial. </description> <content:encoded><p>Its been quite a few years since I have been <a href="http://pooteeweet.org/blog/1753">last subscribed to the internals mailing list</a>. I still hang out in one of the popular core dev IRC channels, follow quite a few on twitter. So I still manage to stay on top of what is happening more or less but not the details in the discussions. Just wanted to put this as a disclaimer. Any opinions in this blog post are opinions formed watching something at a distance and this always runs the risk of being quite wrong or more impartial.</p> <p>To me it feels like PHP development has become much better structured. It also feels like the <a href="https://wiki.php.net/rfc">RFC process</a> has enabled an influx of new contributors that previously simply didn't know how to get their stuff in. There were a bunch of old devs opposed to adding this documented &quot;processes&quot;, saying that &quot;open source is about fun and processes kill the fun&quot;. But to me that was always shining through that argument was that there is always an implicit process and that process is usually ideal for the current people &quot;in power&quot;. As such, there is nothing wrong with that, since if the current people can handle the load, why bother trying to please a theoretical new contributor? But while several core contributors, like Rasmus, Derick and Ilia, have sustained pretty significant levels of contributions, many others have drastically reduced their contributions. More over as the feature scope increases it makes a lot of sense to also grow the number of maintainers. However I guess the really active core group of contributors in most open source project I know tends to hover around 10-20. The beauty of clearer processes is that it can also help in clearer delegation, which can lead to subgroups within an open source organization that again have an inner circle of 10-20 really active people. Now from all I hear &quot;discussions&quot; on the internal mailing list still have a tendency to generate lots of less than helpful traffic.</p> <p>But everything could be turned up side down in the near future. I have been <a href="http://pooteeweet.org/blog/1661">critical of Facebook's initial efforts at trying to reimplement PHP</a>. A change of direction towards a JIT without a code compilation requirement however have made their efforts significantly more viable. More importantly Facebook is now actively trying to <a href="http://www.hhvm.com/blog/875/wow-hhvm-is-fast-too-bad-it-doesnt-run-my-code">enable anyone to run their chosen PHP framework on top of HHVM</a>. They are even <a href="https://groups.google.com/d/msg/php-fig/iwMXyrruwvk/z_ZELhZBAU8J">actively soliciting feedback from framework authors</a> where they would like HHVM to go next in terms of language features. If you compare this to current PHP internals where it seems to be a <a href="https://wiki.php.net/rfc/annotations">never</a> <a href="https://wiki.php.net/rfc/propertygetsetsyntax-v1.2">ending</a> <a href="https://wiki.php.net/rfc/engine_exceptions">battle</a> between mostly the older developers concerned with backwards compatibility, no doubt one of the reasons why <a href="http://w3techs.com/technologies/details/pl-php/all/all">PHP has been able to catch 80% of the internet</a>, and framework authors asking for new language features to enable easier development. Make no mistake adopting Facebook specific syntax in frameworks will of course make that code incompatible with PHP itself. Some of this could be &quot;fixed&quot; by a &quot;compiler&quot; that transforms HHVM specific features to normal PHP code, but that would be probably more sad than ironic. Also what about windows users, still a very significant portion of the PHP user base?</p> <p>None the less the proposition seems tasty when wearing my framework hat. But while this is exciting, its at least as much troubling to me. Do we really want Facebook to have final say in how the language evolves? I am not even sure if Facebook really wants this responsibility. I guess other scripting languages have already had to deal with this situation with various popular reimplementations of Ruby (JRuby, IronRuby ..) and Python (Jython, IronPython ..) having scooped up large parts of their user base. Then again I assume these reimplementations have actually also helped grow or at least sustain their use bases. Facebook has hired quite a few of previous PHP core developers though I am not entirely sure how involved they are in HHVM development. But at the very least it could ensure that there is a bit of a trust relationship between PHP internals and HHVM, which is of course quite important in the open source world. <a href="http://www.infoworld.com/t/php-web/believe-the-hype-php-founder-backs-facebooks-hiphop-technology-231012">Rasmus also seems to be sympathetic to HHVM</a>. To me a key requirement for this all to make sense is for more non Facebook employees to get involved in HHVM development. This would ensure that the project wouldn't blow up if for some reason Facebook looses interest. It would also help in making the internal decision process on HHVM more transparent.</p> <p>At the same time I see a huge opportunity here. If I remember correctly it was <a href="http://thieso2.de">Thies</a> that first stated that the goal of PHP internals should focus on making it possible that all extensions could in fact be written in PHP rather than C back at some LinuxTag over a decade ago. With HHVM's JIT this now seems more feasible than ever before. I have long said that building a good API is an iterative process which requires input from many people and early adopters to battle test. However as PHP is written in C the number of contributors are limited and its not easy to get a broad range of testers to put the concepts into real world testing. PECL has tried to reduce this pain point a bit by providing infrastructure for C developers to create and distribute extensions outside of core release process. But to me its still clear that its not a sufficient solution to provide the number of eyes needed to build more complex APIs. So HHVM could help push forward a revolution in the process of adding new functionality to PHP that I have been waiting for since ages.</p> <p>So in conclusion there are lots of reasons to be excited about HHVM's impact on the PHP community. But we should also ensure that in the process the community does not become dependent on a commercial entity.</p> <p><strong>Update</strong>: The performance of HHVM seems quite impressive indeed these days, since Chregu ran these <a href="http://blog.liip.ch/archive/2013/10/29/hhvm-and-symfony2.html">benchmarks</a>, the <a href="http://www.hhvm.com/blog/2393/hhvm-2-3-0-and-travis-ci">HHVM team has released version 2.3</a>, which supposedly reduces CPU load another 20%. <a href="http://about.travis-ci.org/blog/2013-12-16-test-php-code-with-the-hiphop-vm/">HHVM is now also available on Travis-CI</a>.</p> <p><strong>Update 2</strong>: The article has been posted to <a href="https://news.ycombinator.com/item?id=6921697">hacker news</a>, resulting in a surprisingly sane discussion.</p> </content:encoded> <pubDate>Tue, 17 Dec 2013 09:55:00 +0100</pubDate> <dc:creator>Lukas Kahwe Smith</dc:creator> </item> <item> <title>API versioning in the real world</title> <link>http://pooteeweet.org/blog/0/2248</link> <guid>http://pooteeweet.org/blog/0/2248</guid> <category>general</category> <description>We here at Liip are currently building a JSON REST API for a customer. At least initially it will only be used by 3 internal projects. One of which we are building and the 2 others are build by partner companies of the customer. Now we want to define a game plan for how to deal with BC breaks in the API. The first part of the game plan is to define what we actually consider a BC break and therefore requires a new API version. We decided to basically define that only removed fields, renamed fields or existing fields who's content has changed should be a BC break. In other words adding a new field to the response should not be considered a BC break. Furthermore changes in how results are sorted are generally not to be considered a BC break as loading more data or an upgrade of the search server can always result in minor reordering. However we would consider a change in any defaults to be an API increase (f.e. changes in default sort order) or changing the default output from &quot;full&quot; to &quot;minimal&quot; to be a BC break. But I guess we would not consider changing from &quot;minimal&quot; to &quot;full&quot; as a BC break as it would just add more fields by default. That being said, for caching reasons, we try not to work with too many such defaults anyway and rather have more requirement parameters. With these definitions ideally we should only rarely have to bump the API version. But there will be the day were we will have to none the less. </description> <content:encoded><p>We here at <a href="http://liip.ch">Liip</a> are currently building a JSON REST API for a customer. At least initially it will only be used by 3 internal projects. One of which we are building and the 2 others are build by partner companies of the customer. Now we want to define a game plan for how to deal with BC breaks in the API. The first part of the game plan is to define what we actually consider a BC break and therefore requires a new API version. We decided to basically define that only removed fields, renamed fields or existing fields who's content has changed should be a BC break. In other words adding a new field to the response should not be considered a BC break. Furthermore changes in how results are sorted are generally not to be considered a BC break as loading more data or an upgrade of the search server can always result in minor reordering. However we would consider a change in any defaults to be an API increase (f.e. changes in default sort order) or changing the default output from &quot;full&quot; to &quot;minimal&quot; to be a BC break. But I guess we would not consider changing from &quot;minimal&quot; to &quot;full&quot; as a BC break as it would just add more fields by default. That being said, for caching reasons, we try not to work with too many such defaults anyway and rather have more requirement parameters. With these definitions ideally we should only rarely have to bump the API version. But there will be the day were we will have to none the less.</p> <p>First up we do not want to use the URL to version the resources for the obvious reason that this violates the concepts of REST, as this would imply that &quot;/v1/foo&quot; and &quot;/v2/foo&quot; are not the same resource. Remember the &quot;RE&quot; in REST stands for &quot;REpresentational&quot; which means we are talking about representation of state. Therefore a single URI should be used by resource as the unique identifier. Instead to get different representations we should use media types. There isn't really a universally accepted standard for how to encode version information into a media type. So far so bad. To make things worse it gets a bit iffy to define custom media types (ie. &quot;application/vnd.my_api+v1.1&quot;) for different versions as then you would logically also return that as the Content-Type in the respons. This in turn will make generic tools not able to pick up that the response is in fact JSON if its not just &quot;application/json&quot;. A convention to at least make it human understandable is to add &quot;+json&quot; to the custom media type and I guess clients like browsers could be made to understand this convention. Also it seems like browsers also sometimes ignore the Content-Type entirely and simply try to guess by looking at the actual content.</p> <p>Then again there is no standard that defines what a web application is actually supposed to do with an Accept header in the strict sense. Sure there is the &quot;q&quot; parameter which defines the priorities of the different media types in the Accept header. But technically it is up to the server to decide what to make of these priorities and as far a I know it can also choose to respond with any media type it wants to. Meaning a request with &quot;Accept: application/vnd.my_api+json+v1.1&quot; could come back with &quot;Content-Type: application/json&quot;. Obviously if the server does not support the requested media type (f.e. it never did or no longer does) it should return a 416 HTTP status code.</p> <p>However this brings us to the next issue: Should we have separate version numbers for different parts of the API? Having different versions would make sense if we will likely have releases that will touch smaller parts. But this will complicate the life of the API user, who would then need to worry about sending the proper media types for different parts of the API. But a release often approach might still make this quite sensible as long as we then keep older versions supported for a longer time. However if we have bigger releases it might be easier for everyone if we just increment the entire API if there are any BC breaks. Given that we have a small group of API users we might then even force everyone to update to the new API within a defined timeframe. This could be nice because then with every such big release we would remove potentially deprecated code for previous versions.</p> <p>But this brings up to the topic of caching. Caching really requires that we also include the version in the response. So returning &quot;Conent-Type: application/json&quot; would be a no go. It would be better if we would return the actual version of the returned structure in the response, so we are back at returning &quot;Content-Type: application/vnd.my_api+json+v1.1&quot;. This way we could ensure we do not return duplicates into the cache, even if parts of the API got their version number incremented without any actual change in the response. But actually it does not really help us that much to look at the response. For doing the actual cache lookups on a request to be able to determine if we have a response cached we obviously only have the request data: we would need to find a solution so that for example the reverse proxy knows that for specific parts of the API &quot;application/vnd.my_api+json+v1.1&quot; should actually use &quot;application/vnd.my_api+json+v1.0&quot; as the cache key lookup. But this raises the even bigger question, how does Varnish deal with content type negotiation in general? How will varnish figure out how to deal with more complex Accept headers like &quot;Accept: application/vnd.my_api+json+v1.2; q=1, application/vnd.my_api+json+v1.1; q=0.6, application/vnd.my_api+json+v1.0; q=0.5&quot;. Effectively one would need to handle the entire content type negotiation inside the reverse proxy in order to do the correct cache lookups. And as stated before, this would even need to be aware of the fact that f.e. &quot;/foo&quot; might already be at &quot;1.2&quot; while &quot;/bar&quot; might still be at &quot;1.0&quot;. I guess this issue could be handled via the same <a href="http://pooteeweet.org/blog/2033">trick I employed for authentication</a>, ie. translating requests into HEAD requests to let the web application figure this out, but this will add overhead to every request. So at this point I am scratching my head and wondering how to proceed.</p> <p><strong>Update</strong>: An <a href="http://www.mnot.net/blog/2012/12/04/api-evolution">interesting article on managing API evolution</a> discussing what should trigger a version increment and how to plan ahead to prevent that.</p> <p><strong>Update 2</strong>: Another <a href="http://www.infoq.com/news/2013/12/api-versioning">interesting article</a>, this one about the costs of different API versioning strategies.</p> </content:encoded> <pubDate>Mon, 09 Dec 2013 09:28:13 +0100</pubDate> <dc:creator>Lukas Kahwe Smith</dc:creator> </item> <item> <title>What is next for Symfony2?</title> <link>http://pooteeweet.org/blog/0/2239</link> <guid>http://pooteeweet.org/blog/0/2239</guid> <category>general</category> <description>Or rather what is left to do for the Symfony2 community? Obviously there are some missing features, bug fixes, performance enhancements and polish to apply to various parts of our code base. In terms of features, I think the main part that could use some more love is the HttpCache. But by and large, I think we cover everything that we need to cover and we do it quite well. When looking over the 3.0 UPGRADE file I am also not seeing of anything that hurts bad enough that would be a good reason to start working on the next major version. Given that, the question becomes where to direct our attention as a community? </description> <content:encoded><p>Or rather what is left to do for the Symfony2 community? Obviously there are some missing features, bug fixes, performance enhancements and polish to apply to various parts of our code base. In terms of features, I think the main part that could use some more love is the <a href="https://github.com/symfony/symfony/pull/6213">HttpCache</a>. But by and large, I think we cover everything that we need to cover and we do it quite well. When looking over the <a href="https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md">3.0 UPGRADE</a> file I am also not seeing of anything that hurts bad enough that would be a good reason to start working on the next major version. Given that, the question becomes where to direct our attention as a community?</p> <p>Avid readers of my blog might have noticed a theme in recent blog posts. A while ago I noted that core developers of the early days have become a lot <a href="http://pooteeweet.org/blog/2204">less active</a>. Then I posted about the need to start working on higher level code to <a href="http://pooteeweet.org/blog/2205">make Symfony2 more rapid development friendly</a>. Following this post I blogged about what is missing to <a href="http://pooteeweet.org/blog/2221">make Symfony2 truly great for building REST APIs</a>. Now last evening at DrupalCamp Vienna I was asked what is left to do for the Symfony2 community and it didn't take me long to think of an answer: Bundles!</p> <p>We have an insane amount of contributors to the core, helping on small to complex tasks. Yet, if you look over the most popular Bundles on <a href="http://knpbundles.com">knpbundles.com</a>, most are maintained by and large by a single person and with very few contributors. Then again, there is continuous stream of new tickets (both bugs and feature requests). As the lead maintainer of <a href="https://github.com/FriendsOfSymfony/FOSRestBundle">FOSRestBundle</a>, I have repeatedly tried to find additional helping hands but for the most part it is still only me working on the code. <a href="https://github.com/KnpLabs/KnpMenuBundle">KnpMenuBundle</a> and its underlying library has been stalled in development for over a year now. I guess <a href="http://sonata-project.org">Sonata</a> does have a decently active community. So that is good news, then again Sonata has such a large scope these days, that it needs even more helping hands. This is most evident in the lack of work on the documentation.</p> <p>But how to redirect the resources? Obviously people work on the things that they need. Then again, some people also like to work for fame as is evident by the excitement around the <a href="https://connect.sensiolabs.com">sensio connect badges</a> and how much pride people associate to being listed in the <a href="http://symfony.com/contributors">contributors page</a>. We do have <a href="http://symfony.com/doc/current/bundles/index.html">a few Bundles listed</a> in the documentation but this is more a semi random list of Bundles. Maybe one solution is to try and pick a dozen or so Bundles in the community and promote them a bit more within the community? For example by adding them to the docs and giving badges to contributors.</p> </content:encoded> <pubDate>Sun, 24 Nov 2013 12:23:30 +0100</pubDate> <dc:creator>Lukas Kahwe Smith</dc:creator> </item> </channel></rss>If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//pooteeweet.org/rss.xml
