[wp-docs] New WordPress Handbook

[Jacob Santos]

You will have to forgive me for being somewhat disillusioned. I'm sure 
that if the same people that have commit access to the WordPress 
repository have commit access to the WordPress DocBook repository that 
there should be a pretty fast turnaround for patches. That would also 
mean that there would be around 5 to 7 people with commit access, which 
means more people who will be on the look out for committing patches.

The core team has been extremely good with committing documentation only 
patches (what? They don't break anything, so no testing). Whether there 
is a similar experience for this new repository is to be seen. I do hope 
that there is a quick commit turn-around for patches after a review. I 
shouldn't say it will be the experience given that it hasn't been 
released yet, so complaining is premature at this point. Well, there 
will be a wait period anyway, but I do hope that it isn't more than two 
weeks. If it is more than two weeks, then I will say that it is a bad 
experience for the new repository.

Me complaining (You don't have to read on):

I think my problem is more or less, I don't think I should need to tell 
people that I have a patch ready to be committed or reviewed ('commit' 
keyword should work for that). The process appears to be see ticket, 
write patch, submit complaint to wp-hackers or IRC to have them 
committed. God help you, if the core team or someone from Automattic 
disagrees with your patch or the ticket itself. So I always laugh, when 
like the commit team or it is mentioned that, patches are committed 
easily or tickets need patches (doesn't mean they'll be committed). No, 
historically, the process hasn't been as seamless as I think it should 
be. Although, to be fair, I usually work with low priority tickets, so 
that is a good reason for not caring. Not all of my patches were worth 
being committed and some of the tickets I wrote patches for weren't 
worth being part of WordPress.

That said, I haven't had one bad experience with having my patches 
committed, I've had two (and don't ask, I've all but blocked the 
experiences from my mind) and I don't count waiting a long time as an 
bad experience, waiting a long time is a "WTF?". I would say that except 
for a few code patches that were committed really fast (Yeah!), the only 
other patches I've submitted that had good experiences, were the inline 
documentation ones. I've often thought about transferring the tips I 
wrote on the funcdoc blog over to the codex to help those, who might 
give up after their first patch isn't committed in a timely fashion.

Jacob Santos

Charles K. Clarkson wrote:
> Jacob Santos wrote:
>
>> I had to laugh, because I have like 6 or 7 patches for WordPress 
>> which haven't been committed yet and I'm still waiting. I also don't 
>> think you are being sarcastic, which I mean you know, it actually 
>> isn't too easy to have patches committed.
>
> Are those documentation only patches or do they change the code? Do 
> you find your Inline Document changes take an equally long time to be 
> committed?
>
>
> > If one or two people from Automattic or outside entity have commit
> > access, then I'll tell you right now, that it won't be easy, based
> > upon the patch process for the WordPress Tests Repository.
>
> I would guess (because I really don't know) that part of the hold up for
> WordPress Trac is the testing process. Even automated testing can
> produce a lot of problems which need to be examined.
>
> In a handbook SVN I would guess that rigorous testing would be mostly
> eliminated. I think the approval process needed to commit changes would
> be the bottleneck.
>
>
> > If [those with commit access] don't think your documentation
> > correction is worth it, then you'll have made the patch for nothing.
>
> It seems that changes to the handbook would be approved by some small
> group of people. We have to assume an appreciable amount of effort will
> not make it into the handbook, but I am not convinced it would be for
> nothing. That same rejected work might fit in on the Codex.
>
> HTH,
>
> Charles Clarkson