Table of contents | |
Technical | |
Release coordinator | |
|
Developers | |
|
Packaging | |
|
Security | |
|
Performance | |
|
Continuous Integration | |
If (when!) the Continuous Integration Team will have everything set up, there should be nothing special to do with respect to the release.
|
Infrastructure | |
|
UX & Themes | |
|
Non-technical | |
|
Documentation | |
|
Communications | |
|
Branding | |
|
Community Building | |
|
Configuration Profiles | |
|
Wishlist Triage | |
|
Dogfood | |
|
i18n | |
|
Legal | |
|
Video | |
Tentatively:
|
Analytics | |
|
Consulting | |
None identified at the moment |
Finance | |
None identified at the moment |
Fundraising | |
None identified at the moment |
Admins | |
|
Questions | |
|
If I participate in a release, how many hours do I need to invest? | |
There is no simple answer and "it depends".
Assuming we have 20 people in all. And they each invest 15 hours. That 300 hours will make this release be very smooth. And as we play our cards right and document everything (we are a Wiki community right?), the next release will be that much easier. We are *not* in a micro-managed environment. Regardless of what team you are in, it is important to be flexible and attentive to the needs of other contributors which depend on them. For example, improvements in the release script (which might require some Developers' help), Documentation would need a script that checks all links to doc.tiki.org -> http://dev.tiki.org/How+to+release#script_to_check_all_links
alias
|