Hi,
In regards to the problem the requiring documentation I don't think it would be that bad as it sounds. If everyone would just write even simple bootstraps like : The feature X has been updated/changed in order to perform more cool stuff and you can do that by adding/changing this and that into the existing/new code then I believe it wouldn't be a problem even for someone else to pickup and extend that documentation. Also since everyone would know about this 'requirement' then I think the merging of PRs wouldn't be delayed so much since the people doing PRs would know about it. As for people being afraid to do PRs. Indeed, some of them might be. Others could be just lazy, but I think for the most part, the lack of a guideline for each components, their scope and how they should be used/extended/what's expected from them pushes them away, along with the how to use them documentation as well. For me it's really hard to do a PR because sometimes I don't know what should I do about the Configuration component part of something, or about how the component itself should work in the end and given the fact that my schedule is pretty tight at times I might abandon doing a PR just because I'd need to look at a ton of source code before doing anything. Plus even if I do a PR, it might not be in the Symfony2 way of doing it, see the lack of general direction I was talking about. Kind regards, Florin On Thursday, March 22, 2012 1:16:18 AM UTC+2, Lukas Smith wrote: > > > On Mar 21, 2012, at 14:48 , DlSnIpEr wrote: > > > Hello, > > > > After a chat with vicb I've decided to open this thread. > > Basically I see two major flaws in the current way Symfony2 community is > organized and I believe if these would be covered the we could drive the > framework to something even better. > > Since both of the issues are on the same grade of the relevance I'll > just list them in a random order: > > i agree that there is room for improvement and the 2 topics you mention. > > > a) the lack of documentation when a BIG change is done; > > i am not sure if mandating documentation is the way to go. as a matter of > fact it might worsen the issue you note in b). but we just need to get more > people involved. in general the barrier to entry is ridiculously low to > help on the docs. heck you dont even need to really understand git thanks > to the online PR creation via the edit button on github.com > > > b) the time it sometime takes for a PR to be either merged or rejected. > > vicb has improved the feedback end of things quite a lot in the short time > since he was hired to work on this. > i also think that on the "push" side too many fellow developers are too > shy to "fork" PR's and push them forward. > aka just fork the repo that the PR originated from, take the branch and > continue the work. then either send a PR to the repo that originally send > the PR or create a new PR referencing the old PR. the original commits will > be around, so its not like someone would be taking credit for other peoples > work. > > regards, > Lukas Kahwe Smith > [email protected] > -- 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
