@stof it's true that most of the current PR don't provide the documentation for it but on the other hand having a two-step good-to-merge process would ease up the problems with it.
First and foremost the PR should reach a state as close to final as possible in terms of features and code then it should be flagged as good for merge (or something that reflects the state better). Then the PR should cover all the other aspects before needing to be merged like CS and documentation, or anything else that's decided to be done in this step. When the second step is done the PR should be changed to ready for merge and be merged as soon as possible. This should be done for every type of PR, feature addition, feature change and bug fix. This way if for example one does the code for the PR but becomes unavailable then someone else could pickup the documentation/CS for it and do it so that the PR can be merged. I believe that people that would want a certain PR to be merged would then be motived to finish the reminder of the process for a PR to be accepted if the need occurs. Also, if we'd have a roadmap with the changes planned for each release that could be interactive, vote for a certain feature to be done faster that the other and so on then people would know when to expect a certain thing to become available. For example see the way YouTrack from JetBrains allows it, see http://youtrack.jetbrains.com/issues/WI for PhpStorm/WI as an example (but not as yet another issue tracker), which I believe it's a very good way to keep track of what users want merged/implemented faster. I know that Symfony is based on a community of contributors, it's a different model from JetBrains' one, so maybe voting for features wouldn't seem so obvious but in the long run contributors would be able to channel their efforts better imo. Also validating the CS on the second step would allow one to focus on doing the functionality first then fix any quirks remaining in the code would ease up the review process of the PR, where possible. And a well defined checklist for a PR to cover would also help keeping track of things fresh contributors need to handle to know that their PR can be merged or not. -- Florin On Monday, September 17, 2012 6:57:28 PM UTC+3, Christophe COEVOET wrote: > > Le 17/09/2012 17:51, Michael C a écrit : > > I personally (from experience) have found that features blocking a > release can end in disaster and can upset the whole principal of a > time-based release model as the feature can end up delaying the release; > especially if it’s a feature that many want but not many want to help with. > > > > As for > 5.3, at the moment 5.2 is the most used PHP version; followed > closely by 5.3. However the amount of users/hosts using 5.4 is currently > quite small and isn't worth thinking about until at least 2.7 or 3.0 (2015 > or later). The fact that 5.3 was first released in 2009 and the fact that > it still is not as used as 5.2 (2006) is shocking. > > > > I think having to complete the whole checklist done for something straight > away for something that might not be used might put off new contributors. > As has been suggested a 2-step PR process where after it is mostly done; if > it looks like it will be merged then complete the checklist (documentation > etc.) rather than straight away. This also means that if the developer is > asked to change anything significant this can be done before documentation > etc. is written and it therefore means that does not also need updating. > > Merging the PR before the documentation PR is done is a bad idea IMO. It > will lead to the same issue than currently: no doc PR done in many cases. > However, as Fabien said in a previous mail, having the full checklist is > not required to open the PR. It would be required to merge it, meaning you > can start writing the doc once the code review has validated the way it is > done. > > -- > Christophe | Stof > > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
