Saturday, August 25, 2012

Plone South America Sprint Report: Day 1!

Holy Moly! Plone Symposium South America has been amazing, and the strong local community really shined through today at the sprints. I usually don't do these report things but I'm just so golly proud I'm going to gush about all that got done today at the sprint that has no name!

Fun Facts:
* 18+ new contributor agreements already
* 6 people made their first commit to Plone core today already. Many of these people have been plone users/integrators for 5+ years so I'm really excited to get their input into core going forward
* Plone has an amazing community in South America that takes names and kicks ass
* Only 2 machines had buildout issues and both were resolved in under 10 minutes. That has to be some kind of a record.

plone.api gathered even more momentum. A sampling of what got done:

 * closing open tickets and adding several new methods
 * update error reporting so that errors are useful
 * support for localized documentation in sphinx
 * tests for dexterity support
 * code for granting roles locally and globally

plone.api.json was born and core implementation completed. Testing, docs, and hopefully a demo will be worked on tomorrow.

The Plone TODO tutorial is almost done. We did a coding dojo with 6 people, 3 of which were php developers, to test the documentation and find holes. It could use a couple more passes and some refining but please check it out and report bugs there! It is fully tested, and will be guaranteed to work with new releases of Plone.

Internationalization of buildout.coredev docs into Spanish and Portugese has been started and a LOT of progress is made. It's become very clear to me personally that getting started in Plone has been hindered for a long time by assuming proficient knowledge of English. If anyone is looking to translate key docs for the coredev buildout and plone.api into a local language, please join us in #sprint tomorrow or just holler a bit and I'll find you.

Plone IDE debugger has been fixed and now working on integrating rope.

In addition we got several major bug fixes from for, excellent support from Interlegis for wifi and a place to crash, and super yummy pao de queijo.

Who knows what will come of tomorrow. Having a boring weekend? Join us in #sprint!

Monday, May 7, 2012

Plone Contributor Agreements

This is an open letter about my frustrations with the Plone contributor agreement process. I have tried many times to discuss this in a private setting but I feel no movement and have resorted to stupid antics like writing open letters as blog posts. This is my last effort to push this forward.

Dear Plone Foundation Board -

The current state of the Plone contributor agreement process is abysmal. It is careless, out of date, and undocumented at best. Don't worry, I am not talking about e-signing. We all gave up on that. I am talking about simple things that make me want to go postal. If the developers in #plone can get it together and be nice to newbies, you can do the same.

The steps to make it sane are trivial:
  1. Update the agreement. Get rid of the stuff that no one fills in and the fields that you will never follow up on (e.g. "Please write your physical mailing address here, so we can mail a physical copy back to you." Ahem...). Every time some one fills this out at a sprint, they ask what "Program" is and I always respond with "Pretty sure it's Plone... I think...". I also have to ask them to add their github user name and put it somewhere on the bottom (or I forget then have to contact them later).  Other gems in this legal document include: "If you have any questions, or would like something to be changed, ask [Plone Foundation Contact for Assignments Email Address] via email." In its current state, the agreement is a joke. Please spend 5 minutes and update it.
  2. Update the documentation for new contributors. From our communications, I understand that scanned agreements can be accepted. Maybe you should write that somewhere since everything now points to snail mail (used to be a joke, now just sad). You could also have an email address set up so that it doesn't take 3 emails to find out who "gets the agreements now". You could set up one email, such as, that redirects to whomever is in charge of the agreements at the time being. They could even answer questions and you could update certain documents to have contact information once and never have to update it again. Related: internationally mailing agreements is cruel and unusual punishment. 
  3. Update the documentation for superusers. I have run several sprints and have superuser access to everything needed to make things work. I try to do the right thing but I constantly feel at risk. Let me count the ways:
    1. When triaging tickets with patches, I have no idea which people have signed an agreement and we can accept the patch and who has not. This is not fair to me OR the poor ticket reporters that I pester asking if they have signed or not. 
    2. During virtual sprints, such as tuneups, I often spend time recruiting people to send in their agreements. Does this count as a normal sprint? Can I give them perms once I see the agreement? No one knows the rules. Write them down, please. 
    3. Similarly, there is no list of who has and who hasn't signed the agreement. It would make my life so much easier if I could just validate that. People forget if they signed it in the past and then its a whole debacle. Keep in mind that as a sprint host, I am the one who has to answer questions about whether or not agreements are received or what the status is and can they have permissions yet. 
  4. Be responsive. When people sign agreements, especially mail it in, its because they have something they want to commit. A one month turnaround time is horrid. Motivation is a fleeting thing. Furthermore, please don't make people open a ticket for core access in trac. It's annoying. If you get their github username upfront in a certain document, you can just add them. DONE.
  5. Bonus Round: Follow up. How about a nice welcome email? Maybe a link to instructions on getting the buildout going and how to fix tickets? This can be very easily done with a mailing list which could then be used to send updates like "hey contributors, we moved from svn a year ago" instead of people opening tickets in trac. 
In summary, I'm asking you to give a shit about this poop stain of a process. It is a frustrating, out of date introduction to the Plone developer community and we deserve better.


PS. Have word processor, will edit.

UPDATE #1: The email exists! It's If your agreement is in limbo, email them today and ask whats up.

Also, apparently we technically don't accept scanned documents yet. I hear conflicting things so at the moment I guess just... no.

UPDATE #2: There is a list of approved contributors at Quick, everyone click it and watch crawl! It's a half solution since it doesn't actually list the trac username for quick search but at least it's something.