Best Plone 5 tasks to throw newbies at

1

Exploring the possibility of a newbie sprint. Assuming a 1 day sprint, what would be the best Plone 5 tasks to throw at newbies?

2

I would suggest "quality testing". Meaning: firing up Plone, do as many tasks as possible, like creating content, collections, going through the whole of the control panel, etcetera. Noting down what appears broken, illogical, etcetera.

Then have a group discussion, and try to boil it down to clear, logical tickets for the issue tracker. Note that the docs are in early beta as well, so some docs will reflect Plone 4. Pull requests welcome :smile:

If people are good at making screencasts for some more convoluted tasks (like setting up content rules or a custom workflow) that would be very valuable as well.

Oh, and make sure you have a pile of contributor agreements handy.

Seems like a great idea!

3

Hmmm... these are valuable tasks however my target audience is a Python user group so I'll need to figure if it would be appropriate for them. That said, it would certainly be a useful exercise for another group. I'd probably pitch it at an interface design or UX class for example.

4

There are still quite a few issues here: https://github.com/plone/Products.CMFPlone/issues that relate to wording and simple styling fixes.

5

Thanks @vangheem. A plan for the event is starting to come together in my head (perhaps a template for future newbie sprints)

Prep work Before the Day
These tasks can be done as individuals:

  • Curation of ideal, newbie friendly, bugs (to be done by the convenor).
  • An audit of Plone (as suggested by @polyester) where they use the latest build, critique and document any issues (to be done by the newbies).

Orientation
To cover the following topics:

  • The core developer GIT workflow
  • Signing the developer agreement
  • Best practices for debugging and searching
  • Communication channels for newbie help (primarily http://community.plone.org)
  • (if they are working on the theme) Plone LESS variables and working with NPM in case they
    aren't familiar.

Any other suggestions would be appreciated.

6

to prep work, add:

  • announce it on time to the rest of the community, including timezone and starting/closing time, so people in other timezones can chime in and help out on IRC.
7

I should probably introduce them to IRC also (though I'm using it less personally nowadays).

8

during sprints, it's still the best. You shouldn't be really saying "lunch break in 5 minutes" on community.plone.org, whereas that's perfectly reasonable on the #sprint channel in IRC.

So yeah, IRC still rules as sprint tool.

9

Another concern. We don't know if someone coming to a newbie sprint wants to become a regular contributor to the core. Assuming they sign the contributor agreement, is that enough (with no code contribution history or community involvement)? Just want to be able to communicate the correct information to participants.

10

@polyester I'm aiming for 1 month of notice for this sprint.

11

Do you have to have signed a contributor agreement to file tickets?

12

No, you don't, not for filing tickets. And even pull requests to documentation can be accepted, for instance, if you say "I agree this patch will be under Creative Commons licensing".

But if it's a sprint, it's a good thing to do. It also conveys ownership and trust towards the developer, and gives the sprint leader(s) an excellent opportunity to explain the best practices again (always pull requests, no direct pushing, pep8, etcetera). And it's a good time for that "with great power comes great responsibility" speech :wink: