Project management:Idea dump

From Post-Apocalyptic RPG wiki

Jump to: navigation, search

Idea dump.png This article is an idea dump!

Idea dumps are utilized by the different departments to keep their department starting pages clean. The idea dumps can be used to dump notes at the wiki and flesh out work in progress articles. Once the articles have been fleshed out in detail, make sure you properly categorize them and remove them from the idea dump article.

Welcome to the idea dump of the project management department!


How meetings should work

Meetings are not where brainstorming takes place! We can brainstorm on IRC and forums on a daily basis, but meetings should be for making substantial decisions on the direction of the project, based on an informed basis (= a well fleshed out proposal).

Proposed new meeting workflow:

  • Brainstorming/tossing around ideas on IRC and forums
  • Somebody steps up, preferably somebody with prior experience in the field and writes a feature (or tool/infrastructure/code) proposal, incorperating the valuable ideas collected in brainstorming phase
  • A fleshed out proposal should always recommend one of the options presented in it; it's also fine if the proposal comes to the conclusion that it doesn't matter which option we choose, as long as this conclusion is the result of actual research done; in this case the proposal should state so and encourage us to simply pick one option and start implementing it
  • Meeting gets prepared and devs are informed what topics will be presented by who; so they have a chance to read through the proposals in advance
  • Meeting takes place, speaker (usually the one who fleshed out the proposal) gives a short talk and recommends one specific option how the proposal should be implemented
  • After discussion has taken place, we settle for the best option; we shouldn't vote on it if not necessary
  • Proposal becomes accepted and is ready for implementation down the line

Project management links

Build toolchain & packaging

Notes from former version control article

  • Interested programmers could set up their own PARPG repository. They could maintain a copy of the PARPG trunk there, play around with the code and provide patches for the official trunk rather easily this way. Syncing might be far easier with this approach than sending in patches via Trac.
  • Free git hosting:
  • Free mercurial hosting:
  • 3rd party repositories could be listed at the VCS article at the wiki to be aware who's running a repository.

Sprint meeting summarization

Heya dear sprint developers. Thanks to everyone who participated in yesterday's sprint prioritization & planning meeting.

This is a summarization of the events to help the ones who were not around yesterday, but who would like to participate in the sprint nevertheless. This said: it also contains some observations about the sprint meeting and brings up issues we didn't originally foresee.

Notice: For future meetings, the results of the meetings will be just summarized at the specific meeting article at the wiki. I'm sending this summarization around by email to ensure that everyone is on the same page concerning the sprinting process, so please read this email carefully!

Sprint article: This is the official sprint article at the wiki: Please watch it closely during the sprint!

Sprint goal: We agreed upon the "character customization based on stats and attributes"-user story as primary, essential sprint goal. Associated tickets:

We also agreed upon the "standard build system" user story as secondary, optional sprint goal. Ticket:

Sprint location: Sprint development takes place in a sprint branch. Use this URL to check out the sprint branch:

Scribe role: Technomage acted as scribe who tracified user stories and sprint tasks in yesterday's meeting. My personal impression was that one scribe is kept quite busy with tracifying the new broken down user stories and sprint tasks. Therefore the scribe can't fully contribute to the discussion. My personal proposal is that the scribe just tracifies the broken down user stories we'll commit to during the sprint. The actual department-specific sprint tasks should be written by developers from the department as they know their field of work best.

I've posted a thread for feedback on this topic on the sprint board of the forums:

Please post your take on this topic there!

Timeboxing: Timeboxing worked quite well in the beginning, so thanks to everyone for the discipline in that regard. Unfortunately breaking down the chosen sprint goal into essential and optional user stories took far longer than originally anticipated. We should think about ways how we can improve sprint meetings in this regard. Moving some parts of the sprint meeting tasks to the forums for future sprints might be an option.

Sprint tasks: Breaking down the user stories into sprint tasks took quite some time and we didn't manage to break down every identified smaller user story for the sprint into actual sprint tasks. Nevertheless the most important work was tackled during the meeting: every department has some starting tasks for the sprint so they can get their hands dirty. This said: the sprint backlog has to be constantly updated to reflect: 1. Who's currently working on what 2. What's the priority of the different sprint tasks 3. What are new sprint tasks that we didn't originally identify in the sprint meeting

Sprint teams distribute the tasks they work on among the sprint developers. The tasks aren't assigned in a top down way but they're simply taken by sprint devs. This said: it needs quite some communication and coordinator for this to work. If you work on a specific sprint task, assign the ticket to yourself in Trac. If you're working on a sprint task that hasn't been tracified yet, write a Trac ticket for it and assign it to yourself! If you've finished working on a sprint task, close the ticket and commit your work into the sprint branch. Reference the specific sprint task ticket in the commit message! These sprint teams owns the entire sprint backlog, it's yours!

Sprint team: A list of all developers and interns who signed up for the sprint can be found here:

Sprint process: Unfortunately we didn't have the time to explain the sprinting process in detail yesterday. As it's essential that every developer understands how the sprint process works, please bring up any questions you have about the process at the sprint board of the forums:

I'll post a FAQ at the forums there later that will try to answer the most frequent questions.

Meeting log: Full meeting log can be found here: Starting at 16:00:33, log timestamp timezone is UTC-7.

Twice-weekly Scrum meetings: Unfortuantely I screwed up the initial doodle for the twice-weekly Scrum meeting as I didn't activate the timezone conversion feature.

Here's the new, fixed version. Please fill it out so we know when we should have our twice-weekly Scrum meetings to report back progress and raise awareness for impediments:

We'll have our first twice-weekly Scrum meeting in the upcoming week, so please fill out the doodle until Sunday evening so we can chose a timeslot for the meeting at this point.

Lessons learned:

  • Ensure that everyone on the sprint team has an own, working Trac account
  • Ensure that the timezone conversion option is activated for future meeting doodles

Greetings, Martin

Personal tools