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.
Projects
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.
Team discussions:
- 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.