sup i got a conf call in 4 minutes, so we may need to pick thi sback up later :| Basically i'd like to find out how you gather the requirements for each release and is it possible if you could provide me with some requirements information its alot easier to have a chat log to reference rather than saying i just found out :) thats fine, you go right ahead! back again hi gathering requirements... yep :) well, each engineer is involved in the community side, through IRC or forums so each of them knows (in their area of expertise) what needs to be done me, also being involved on the professional services side, know what real-world clients are trying to accomplish with our technologies and the shortcomings that exist in the latest versions of deki so before each release, we gather all the devs in a room and talk about what we think should go into the next release So community input is a large base of your requirements, do you also evaluate and listen to your clients? some of them are pretty straightforward - for example, eric shepherd at mozilla gave us a list of gripes that he gathered from his community which we boiled down into bug reports on our side yes but not in a direct way i don't sit down with them and ask them what they want - that usually ends up with high-level features that aren't very well thought out sure most people, when they deploy deki, do not know what htey want they simply know that it's the best decision going forward because it's so flexible so when you ask for real world examples of what htey want, they'll provide ideas like: "social networking" which isn't a bad idea in theory, but if that's the only requirements you have, it's no good so i take an approach of "what are they trying to solve?" and then i'll kind of mold that into an idea an example of this is page properties in lyons nobody directly asked for this feature but it was clear when i was talking to clients, that what htey were looking for was a static structured data format per page, per user for example, they wanted users to be able to set custom fields that were enforced across all users - "rea name", "occupation", etc. (the basis of social networks) so that's where page properties came along yea when steve was working on deki extensions, he realized that keychains would be useful per-user keychains and max was also working on refactoring the architecture of files (because it was so atrocious) and realized that in essence, file descriptions are file properties if you're listening closely to the community, you tend to find patterns of weakness in the software and then it's our responsibility to make sure converge those into real features definitely so it's really important that our engineers remain close to the community in that regards, because the community has traditionally been a couple months ahead of what the customers say they want and then, we'll sit in a room, put up a whiteboard, and throw up all the ideas and then we'll talk about the overlap between features at this point, i also start talking to sales/marketing about the message we want to drive home with the next release there needs to be a story behind the release so with that knowledge, we'll start making decisions about what features make it in, and what features don't and then, of course, there's the simple matter of resource allocation - what engineers can be tasked to what items. in shorter release cycles, it becomes easier to manage this schedule but with longer release schedules, it becomes more difficult ... so the req gathering is generally the easy part there is generally very little disagreement at that point I dont know if you're pausing or typing :p paused :) well that helps alot i know its annoying but could i ask a few more questions sure go for it only a few! i swear :) it's fine - i need a break from my normal routine today and i'm starting to get an idea for a blog post :P :) i'll send you the stats i have im not sure if they are any good fantastic! but you can have them thanks right another thing is design are there any examples of design which satisfies the requirements and what design mechanisms do you employ design mechanisms? i'll need a bit more clarification on that one For example, interaction with a database may require data flow diagrams oh yeah, we don't really do that or possibly, class diagrams for the OO part of c## isn't that more of a waterfall approach to design? i mean, we do specs and we do a lot of whiteboarding but we don't throw together a lot of design documents the team is small enough that a whiteboarding session for a day gets everybody on the same page well what design approach would you say you perform? im just going through the motions :) probably a mixture of waterfall/agile i'm not sure any of them are silver bullets we do a lot of aggressive iterating i know :) i've had to sit through your bug fix list i guess i could look at notifications and page properties for an example page properties ... max went off and implemented what he thought was best steve then started looking at webdav properties and poo-pooed on max's idea so they went off and came back with this: http://wiki.developer.mindtouch.com/User:SteveB/Lyons_-_API_Work_Items/Resource_Data_Model this was based on what htey felt were shortcomings in the first iteration, and then the limitations of using webdav for this particular feature thats perfect and then based on that, we've gone and implemented it but we've found issues with it as we deployed and tested so, to my dismay, we've written a couple of update scripts (== huge cost) to fix up limitations with them that shows design methodologies that have been implimented and then refined to meet a requirement bang on yes, i guess. i'm not much the academic type ;) :) well this is what i was looking for awesome spot on :) I have to perform a maintenance activity as part of my assignment (last q :) sure what stages would i have to go through where would my requirements come from (im assuming the bug list) hmm? Here, 'Oridyce the design of the proposed maintenance activities, showing evidences of interaction with othr developers' :P * produce oh i also am required to 'identify the requirements of the maintenance activity' sorry i know im harping on now :) http://wiki.developer.mindtouch.com/MindTouch_Deki/Specs/Lyons/Metadata and then the link i sent above check the revision history (or am i misunderstanding your q?) 2 seconds, just reading :) Almost basically, think of me as a member of the team for a day i need to do a few things 1) obtain some requirements so i have a reason for wanting to impliment the new change ah yes mantis is the best place for that 2) once i have the new change, i need to design and impliment that change we also ping over skype and irc http://bugs.developer.mindtouch.com/view.php?id=5894 unless it's a new feature design decisions are generally left as the dev's responsibility sure and once it gets checked-in (we all get the svn logs), if there's something fundamentally wrong, we'll ping http://bugs.developer.mindtouch.com/view.php?id=5896 so can i just grab the sourcecode and try and fix one of these bugs for you guys? theres no way in hell you have to accept it :) well, you don't have svn access but you're free to submit a patch for the time being how would i submit the patch? (we're working on the whole svn issue soon - i'm refocusing my attention on the community aspect after lyons ships) you can attach it to the bug cool :) here's another example of a convo between community and dev: (this one actually inovlved more design decisions, wihch were discussed in-person) http://bugs.developer.mindtouch.com/view.php?id=5270 thanks np right, im going to work my socks off and try to document a change apply a patch hah sweet or atleast discuss it i reall appreciate your help you've been more than kind :) have a good rest of the day! thanks np you too!