Release Roles

The Tiki community is organized in many teams. At release time, here are the responsibilities for each.


Release coordinator

  • Overall management & planning, schedules. See: Release Coordinator
  • Also known as "Release manager"

Developer Team

  1. Fix bugs
  2. Provide documentation team with basic information about features.
  3. Update all Developer documentation to take into account new version number and features. Ex.: Download, Commit, Hello World, etc....
  4. Review all Experimental branches and delete if appropriate (could be done at any time, but a 6-month reminder is good).

Packaging

  1. Branching
  2. Run Release scripts, etc.
  3. Packaging Alpha/Beta/RCs
  4. Improve the release process
  5. Update List of all code contributors
  6. Submit to and keep up to date each of the Auto-installers and Distro
  7. Maintain Installation guides

Security

  1. Review all previously reported issues on dev & sent to security list
  2. Contact all people that have helped in the past.
  3. Proceed to security audit as per our release procedures.
    • run doc/devtools/securitycheck.php and check each "potentially unsafe" file.
    • Check for presence of all .htaccess files
    • Security Check exceptions
    • Add files to robots.txt (printed pages, etc.)


Wishlist

  1. Test/triage all reported patches
    • Contact them to invite them to commit directly and be active in the community
  2. Test/triage all reported bug reports
    • Test the fixes and close the bugs
  3. Review How to Submit a new item on the Wishlist to make sure it's still relevant and update to take advantage of new features.

Testing

  1. Instructions for Tiki Testers


Quality

The Quality Team formally starts after the .0 release however, these experienced developers are still checking the commits (albeit less systematically).

Documentation

  1. Make sure basic docs are updated (Requirements, Download, Backup, Install, Upgrade and Initial Config, etc.)
  2. Check all links from the app to the sites -> Add & Remove to doc:Keywords & dev:Keywords see Restore Help Pages
  3. Make sure all new features have at least a stub.
  4. Make an .odt and .pdf version of the current documentation for stable releases.

Communications

  1. Make doc:Tiki7 nice
  2. Update Fact Sheet
  3. Publish news on info.tiki.org, SourceForge, Freshmeat, etc.
  4. Update info on all Listings
  5. Inform Control Panels to update (Fantastico, etc.)
  6. Inform demo sites. (OpenSourceCMS.com, etc)
  7. Promote on all relevant Social networking sites. (Facebook, etc.)
  8. Promote on all Wiki and CMS-related resources (ex.: CMScritic.com)
  9. Update Promo Sheet
  10. Update Features list & ratings
  11. Review Tiki Welcome, as all new registrants are sent to it after validating their email link.


Community

  1. Identify new volunteers
  2. Monitor support forums and help identify any blockers & regressions.
  3. Implement new Dogfood features on *.tiki.org to help test and make the community more open efficient and welcoming

Profiles

  1. Determine which profiles are "Featured" and make them excellent
  2. Review, evaluate and categorize all profiles


UI & Themes

  1. Make sure bundled themes work well with featured profiles.
    • Install trunk, apply successively the featured profiles(external link).
      • These profiles may change a bit feature-wise for 4.0, but for CSS, the are still excellent tests
    • For each of the features profiles, apply also the test all themes profile(external link)
      • You will then have a drop down to easily successively test all themes.
    • Test with the major browsers, including IE6
    • Click around and fix what you can (layout, bad colors, missing padding, etc.)
      • Make sure to try to fix main problem so it fixes in all themes (ex.: layout CSS.)
      • Keep in mind that bundled serve as a base for most of the custom themes that are made. Thus, they need to be as good as possible!
  2. Make sure basic features are intuitive (install, admin panels, etc.)
    • Pretend you are a end-user and install Tiki and address any unclear user interface

i18n

  1. Get in contact with all past translators and coordinate updates
  2. Upstream/merge/resolve potential conflicts of translations in stable branch to trunk
  3. Update % of completion stats
  4. Help translators prioritize most important information to translate. Ex.: Promo Sheet.

Infrastructure

  1. Progressively update all *.tiki.org sites to the new version. The ultimate DogFood!
    • The goal is that all major sites are upgraded before it's released.
      • Order is Branding, Themes, Documentation, Community, Development, Profiles, Info.
  2. Monitor for broken links, performance regressions, etc.
  3. Update official version numbers up to date (which is where all the Tikis connect to know if they should update).


  1. Check the licenses of all newly included or updated code.

Admins

  1. At each release, Admins do whatever needs doing, and whatever falls between the cracks.


Questions


If I join a team, how many hours do I need to invest?


There is no simple answer and "it depends".

  1. The number of hours is "as many as we can get". The more people we are, the more we can split the load. And the easier it'll be for all.
  2. There is a law of diminishing returns(external link). Before putting hundreds of hours on X, we should try to improve Y which becomes our weakest link.
  3. On the other hand, volunteers can't interchangeably do any task. It's according to their interest and type of skills.
  4. And some roles are easier than others because of more involvement in the past. Ex.: The release scripts are so much easier than they once were.


This being said, globally, for most roles, if we get 15-25 hours. It makes a significant difference.

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.

About what each team will specifically do, ideas are above. But we are not in a micro-manage environment. It's up to each team to determine their priorities and to be flexible and attentive to the needs of other teams which depend on them. For example, for the doc team to be efficient, they would need a script that checks all links to doc.tikiwiki.org -> http://dev.tikiwiki.org/How+to+release#script_to_check_all_links(external link)

Contributors to this page: marclaporte42827 points  .
Page last modified on Wednesday 08 June 2011 08:53:16 CEST by marclaporte42827 points .

Switch Language

Subscribe to Tiki Newsletters!

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other news!
Contribute to Tiki

Shoutbox

Torsten1785 points , 13:29 CET, Fri 10 Feb. 2012: Next webinar at Thursday, 16. of Feb. 2012 (21:00 UTC) at http://tiki.org/live
ricks9915694 points , 16:36 CET, Thu 19 Jan. 2012: Free webinar, today at 21:00 UTC http://bit.ly/zeH0UE
marclaporte42827 points , 05:17 CET, Tue 17 Jan. 2012: Tiki 8.3 and 6.6 LTS now available: [Link]
ricks9915694 points , 13:34 CET, Tue 20 Dec 2011: Tiki 8.2 & 6.5LTS now available: [Link]
ricks9915694 points , 18:00 CET, Fri 11 Nov. 2011: Tiki 8.1 now available: [Link]