As many of you know WCSF this year also has a community summit and then team working days. This is a great chance to meet face to face and work on making this team the best it can be.
Whilst, those of us that are going to be there are excited, it’s also important we make sure we include those of us not going to be there. As was discussed in yesterday’s meeting we’re going to make sure everything gets posted for everyone to see. There will be lots of note taking!
After a bit of discussion the following is our suggested format and topics for discussion. I’m putting this up here for 2 reasons:
1. To get input from those who are going to be there and those that aren’t. Are we tackling the things you think about important? We can’t tackle everything but lets get a broad spectrum and try and make sure we accomplish things.
2. Show what is planned. I’m excited about what could come from it and I think it’s good to put up to be accountable to it in future weeks.
Tomorrow, I will review and check the comments haven’t got anything that we missed to include and should be. After that, the agenda will be fixed. We have to send it off before the event.
I hope you will agree with me, this contains some exciting content.. so here we go:
Agenda for theme review team:
Contribution day: Review focus. Getting new reviewers onboard, live training and mentoring. We may have to use USB’s for this due to bandwidth and no contribution pack yet.
Community summit day: This isn’t team focused.
Team days – projects and organised discussions:
I’ve split these into projects, discussions. We can be fluid just setting some foundations.
Depending on the size of the team we can split the following projects into 2 groups for maybe 1/2 a day:
- Contribution pack project: Get a prototype by end of the days.
- Doing_it_wrong theme project: Get a prototype by end of the days.
An all group project for a chunk of sessions should be:
- Guidelines and handbook project: Spend some time refining and making this up to date. The goal is to fix holes.
Role specific discussion:
- Admin and key reviewer discussion. A discussion for those in roles. Focusing on workflows of making live and guidelines.
- Mentorship program review. What is working and what isn’t? Include mentors and mentees only to focus.
- State of theme reviews discussion. An open discussion for entire team.
- Mentorship program review. What is working and what isn’t?
- Tools review. This will include discussion on what is working, what isn’t. Also a discussion on what can/should go on Github GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ (theme check plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for example).
- Communication review. What is/isn’t working? Mailing list, IRC, make.blog. How can we make things better? Should we have a monthly hangout?
- Reviewer retention and reward discussion. How can we get more people to stay and reward them?
- The future of theme reviews discussion. Open discussion for entire team.
Outside of this we have the following goals:
- Get to know each other in real life.
- Work towards uniting the team.
- Make our tools and handbook better.
- Make connections with the a11y Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team and talk about how we can work together.