> 1) I'll move forward shortly with my original plan of (a) getting a doc > ready so we can track and encourage some important docs to be reviewed by > core devs and (b) organize a hack day on the docs. > It think this will be really really usefull for the documentation. We have tons of great documents, but not everything is correct and up to date right now. The docs grown very fast the last year and I think we were a bit loose with reviewing the docs in the beginning. We should be more strict and we should think about a strict review/PR process (somewhat the same as the main symfony branch has). I started to create documentation standards, but we need to do more on this.
Keeping the docs up to date is really hard, especially if the docs are big. One or two bug hunt days and core dev reviewer will help us, but we should look for a new correct way to do this fast. 2) @Stof I'm for more help and I've been thrilled to have guys like > @WouterJ lately :). Where I need the most help is not closing issues, but > preparing for them to be closed - commenting that things are fixed, > creating PR's for issues, determining that issues are invalid, and helping > to review PR's. Immediately, I'll do a more active job of commenting on > PR's to highlight their issues. When PR's don't get merged quickly, it's > usually because there is a problem - i.e. it needs heavy review (new > documents), contains a mixture of changes to multiple branches (and thus > needs to be split up), or maybe is deep enough in some code that it > actually needs to be tried and tested out. I'll highlight these and > hopefully get some help with these more time-consuming parts. > I don't think we should have other people that can merge PRs. We should have one man who maintains what gets merged and what not. But I think you get more time if you don't need to check if issues/PRs needs to be closed. I like the idea of @stof, in the way that you have a helper (this don't need to be myself) that helps you with removing old issues and labeling them. I think labels are a great idea to keep your issues and PRs organized, we should use them more than we do now. > 3) I like the versionadded because it tells me "oh, that's a new feature, > that's why I didn't see it before" or "I need that! But I'll need to > upgrade Symfony" or "I could have swore the function was called something > else - ah, it was renamed in 2.2, that makes sense". So I'm a big +1 for > this tag. BUT, you're right that on Sf 2.8, it would be a bit insane to > still have so many of these - e.g. "New in 2.1!". I think we should do 2 > things: > > a) Whenever we have a new version/branch of the docs, we remove all > versionadded tags that are for versions whose end-of-life had been reached > at the time of that version being released. For example, suppose the > end-of-life date for 2.1 were May 2013, and 2.3 comes out in June 2013. > When we create the 2.3 branch, we would remove all of the 2.1 versionadded > tags. This should keep things relevant. > > b) Add to the docs contributing page to formalize this. I'll open a PR > for this and we can get the details of it right there. > We should also think how long we maintain a version. For instance, the 2.0 version has reached his end of life, shouldn't we remove that branch and remove all versionadded:: 2.1 blocks? -- Wouter | @WouterJ -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
