+1 It will be really good if Symfony project will use youtrack (it's free for open-source projects)
On Monday, September 17, 2012 9:49:26 PM UTC+4, Florin Patan wrote: > > @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
