On 01/15/2013 01:27 PM, ryan weaver wrote:
Hi guys!
Let me sum up a few thoughts:
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.
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.
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.
That sounds reasonable. Describing the usage on the contributing guide
will help a lot to remove the confusion.
Do you plan to write a symfony.com blog post in order to describe all
those changes and call for help ?
Thanks,
Victor
Thanks!
On Tue, Jan 15, 2013 at 4:37 AM, Victor Berchet <vic...@suumit.com
<mailto:vic...@suumit.com>> wrote:
so an API doc
Ryan Weaver
US Office Head & Trainer - KnpLabs - Nashville, TN
http://www.knplabs.com <http://www.knplabs.com/en>
http://knpuniversity.com
Twitter: @weaverryan
--
--
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
