Re: [dev] An attempt of a summary: specification process possibilities
Hi Bernd, On Thursday, 2006-11-16 16:08:34 +0100, Bernd Eilers wrote: > The questions where I am currently unsure about are the following: > > 1.) can automatically move all featuremails/api-changes from state draft > to state finished when the state of the CWS moves to state 'ready for > QA' or should we do that when the state of the CWS moves to 'integrated' If integrated. > or if should we not do any automation at all and leave it up to the > developer to change the state of the featuremail and apichange only? After integration the feature as desribed by the featuremail is final, if it wasn't, a new CWS would be created and the feature be changed, with a "feature changed" mail, if needed. There is no sense in keeping the featuremail in draft status and burden the developer with having to remember to set it to final. > 2.) Can there be a case where a feature mail is "finshed" but must still > be changed You never know, it might happen. For example if a description is wrong or important information missing. > and what should happen in this case regarding the > mailinglist, resend the featuremail? Yes. > If for 1.) we would decide to declare things final only at integration > Problem 2.) is not there because a change in the feature would be done > in a new CWS and a new featuremail would be needed there for it. True if the feature needs changing, not true if only the featuremail needs changing. > On the other hand QA must have information about the feature when the > CWS is 'ready for QA' and we can not require that anyone in QA get´s > familar with RSS feeds. If the featuremail is a feature of EIS, assigned to the CWS and a task and readable for everyone, the information may always present via the web interface. No need to make it available only in RSS feeds. > Maybe this can be resolved by having 3 states 'draft', > 'published' and 'final' and moving to published with sending to > mailinglist when state changes to 'ready for QA' and moving to > 'finished' with or without publishing to mailinglist also when CWS state > changes to 'nominated'. No, that's just confusing. The featuremail gets final and is published when the CWS is integrated. We don't need extra states that complicate things. Maybe with the possibility for the developer to send out extra draft mails before integration, if needed. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Frank Schönheit - Sun Microsystems Germany wrote: Hi Mathias, Hi Frank & all, At the risk of being caught ignorant: should feature/changes mails on these lists be posted before the CWS is approved? I think that odds aren't low that something might get changed after handing over the CWS, especially in case of new developers. AFAIK policies require mails to be sent when the CWS does to QA - which in fact might not make that much sense. Perhaps we can distinguish between "preliminary" and "final" announcements, the former is sent when the CWS is handed over from the developer, the latter when the final step ends with the CWS approval. Currently we do only have "final" announcements. What´s important to consider is that text from the feature mail gets into the ReleaseNotes if no specification is there by a semi-automatic process looking at information in EIS and in specifications and generating a document which is the basis for the ReleaseNotes. So it´s currently an unfortunate situation that when a feature changes after the feature mail has been send nothing can be done about the entry for it in the database and we might end up with wrong information in the ReleaseNotes. So having correct information in the release notes requires that the featuremail information can be changed or is "final" from the beginning. On the other hand the open source philosophy is to publish early and to publish often. This has the advantage of bringing all possible stakeholders ( eg. QA, documentation, UX, code reviewers etc. ) on board as early as possible. IMHO having two stati for feature mail and api-announcements would be a good solution to resolv the conflict. For personal taste I would name the non-final one "draft" instead of "preliminary" but that´s just a minor issue ;-) I'd prefer an ability to add feature mails in EIS which are not yet sent. That is, I would like to fill out the form for the feature mail, and press some "Send Later" button. The mail would then be associated with the CWS, and only sent when the CWS gets approved/nominated/integrated (whatever). QA can still look at the mails, and development can change them before sending, if necessary. Since a few days we have already association of the feature mails with the CWS via the taskid and the task list in the CWS overview page. There is a new column featuremail and also an new column specification in the task list with links to featuremails and specifications. There also is already a feature in EIS to resend a featuremail or apichange, which is currently used only if there was a network error or similar and it is currently only available in the list of featuremails or apichanges. So IMHO what we need is to make the featuremails/apichanges editable, offer the resend featuremail/apichange directly on the page where you can edit it and add a status flag for "draft" and "final" which would not only be shown in the featuremail/apichange but also be available in the Task list of the CWS overview page where you can find the link to the featuremail. For apichanges we would also need a new feature in EIS to associate the list of apichanges with the CWS. The additional advantage of such a feature - completely independent form the current discussion here - is that for large CWS, you do not need to manually track all the chances (esp. API changes) you did therein. You can write them when they happen, and they're all sent at once when the CWS is finished. We could discuss wether featuremails/api changes should be send as mail only when the status moved to finished or wether to send the first draft as mail also. I personally do like the idea much to have information available as soon as it´s there, for those who are interested. Well if the change did happen and you´ve written about it and you´ve also declared that the information is currently only in draft status there is IMHO no reason to hold back that information, so possible stakeholders can already start to prepare their todo list to be worked on after the momment that the final announcment is there. Therefor I like the idea that Joerg presented to have an RSS feed for featuremails and apichanges, which would contain last recently edited featuremails or apichanges. On the other hand RSS feeds may be not yet a widely accepted medium for everyone so I would like to suggest to keep the mails for the final status and add the RSS feeds for those who would want to get in touch with the information and updates to it earlier. Keeping track only for yourself without making information also available for others would not be possible with such feature but it would allow to keep track and allow others to see what is about to be there in the future early also. The questions where I am currently unsure about are the following: 1.) can automatically move all featuremails/api-changes from state draft to state finished when the state of the CWS move
Re: [dev] An attempt of a summary: specification process possibilities
Hi Jörg, > to go a step further: Do we need such feature mails at all? Couldn't we > instead offer RSS feeds (per project?) which list the most recently > integrated CWSs and their feature descriptions? It's a matter of taste and/or working habit whether you want to read a Feed or a mailing list. I wouldn't remove the mails completely (finally, they have the advantage of being archived in the OOo project), but I like the idea to additionally offer them as feed. > I could imagine that a developer can edit the feature description at any > time he likes and, at the time the CWS with the feature task(s) gets > integrated, the information about the feature(s) gets available Yes!, please let's have this! Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi, to go a step further: Do we need such feature mails at all? Couldn't we instead offer RSS feeds (per project?) which list the most recently integrated CWSs and their feature descriptions? I could imagine that a developer can edit the feature description at any time he likes and, at the time the CWS with the feature task(s) gets integrated, the information about the feature(s) gets available in the appropriate RSS feeds. If someone is interested in the feed, then he can subscribe to it and gets informed when updating the RSS feed. No mails at all. Would this be feasible? Would it be better than the current way? Or is the idea just nonsense? Regards, Jörg Eike Rathke schrieb: Hi Frank, On Wednesday, 2006-11-15 13:43:22 +0100, Frank Schönheit wrote: I'd prefer an ability to add feature mails in EIS which are not yet sent. That is, I would like to fill out the form for the feature mail, and press some "Send Later" button. The mail would then be associated with the CWS, and only sent when the CWS gets approved/nominated/integrated (whatever). Integrated. This would also (again) give some meaning to the "available from" field, which then could be automatically filled by EIS with the release target the CWS was integrated for. Currently the "available from cws soandso" may bear information for QA and people familiar with EIS and CWS integration, but the real release target would be more useful for the general public. QA can still look at the mails, and development can change them before sending, if necessary. So, +1 Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Frank, On Wednesday, 2006-11-15 13:43:22 +0100, Frank Schönheit wrote: > I'd prefer an ability to add feature mails in EIS which are not yet > sent. That is, I would like to fill out the form for the feature mail, > and press some "Send Later" button. The mail would then be associated > with the CWS, and only sent when the CWS gets > approved/nominated/integrated (whatever). Integrated. This would also (again) give some meaning to the "available from" field, which then could be automatically filled by EIS with the release target the CWS was integrated for. Currently the "available from cws soandso" may bear information for QA and people familiar with EIS and CWS integration, but the real release target would be more useful for the general public. > QA can still look at the > mails, and development can change them before sending, if necessary. So, +1 Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Mathias, > At the risk of being caught ignorant: should feature/changes mails on > these lists be posted before the CWS is approved? I think that odds > aren't low that something might get changed after handing over the CWS, > especially in case of new developers. AFAIK policies require mails to be sent when the CWS does to QA - which in fact might not make that much sense. > Perhaps we can distinguish between "preliminary" and "final" > announcements, the former is sent when the CWS is handed over from the > developer, the latter when the final step ends with the CWS approval. I'd prefer an ability to add feature mails in EIS which are not yet sent. That is, I would like to fill out the form for the feature mail, and press some "Send Later" button. The mail would then be associated with the CWS, and only sent when the CWS gets approved/nominated/integrated (whatever). QA can still look at the mails, and development can change them before sending, if necessary. The additional advantage of such a feature - completely independent form the current discussion here - is that for large CWS, you do not need to manually track all the chances (esp. API changes) you did therein. You can write them when they happen, and they're all sent at once when the CWS is finished. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Joerg Sievers wrote:
> Hi Matthias!
>
>
> Mathias Bauer wrote:
>> (1) While developing your feature: discuss feature with people on IRC,
>> mailing lists and whatsoever to your liking; it is *recommended* (though
>> not mandatory) to contact the project lead as early as possible and
>> discuss with QA and UserEx also (not to ask for approval but to avoid
>> problems by early contact!).
>
> Good description in the last sentence.
>
>> (2) While development happens make sure that at the end you deliver a
>> "spec". This could be just an issue in IZ, a web page or a document,
>> details can be described elsewhere. BTW: I consider having an Issue in
>> IZ mandatory as we need to have a reference for cvs commits.
>
> Be sure that your "spec" meets the 'three golden rules' which can be
> used for a review of the "specification"
>
> http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications
>> There is nothing "overweight" included and you have to look at these
> tasks otherwise the integration could (and it will, be sure) fail and
> will cost others time or break the testing, building or whatever in this
> case could happen...
I'm not so pessimistic as you are. ;-) But I agree that it helps
developers if we make them aware of possible problems that can appear
later on and how they can be avoided easily. So our rule set should
include the golden three words ("Complete","Clear","Simple") and the
link to the mentioned wiki page as a resource for explanations of the
meaning and the reason of them.
>> (3) Get necessary builds (perhaps by using build bots) and hand builds
>> and "spec" over by announcing them somewhere(we must define where!) so
>> that QA, translation and documentation can start working on it.
>
> There is already a tool how to announce feature changes:
>
> http://eis.services.openoffice.org/
>
> -> Changes mails
> -> "external" feature
> or
> -> "external" API change
At the risk of being caught ignorant: should feature/changes mails on
these lists be posted before the CWS is approved? I think that odds
aren't low that something might get changed after handing over the CWS,
especially in case of new developers.
Perhaps we can distinguish between "preliminary" and "final"
announcements, the former is sent when the CWS is handed over from the
developer, the latter when the final step ends with the CWS approval.
Ciao,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Matthias! Mathias Bauer wrote: (1) While developing your feature: discuss feature with people on IRC, mailing lists and whatsoever to your liking; it is *recommended* (though not mandatory) to contact the project lead as early as possible and discuss with QA and UserEx also (not to ask for approval but to avoid problems by early contact!). Good description in the last sentence. (2) While development happens make sure that at the end you deliver a "spec". This could be just an issue in IZ, a web page or a document, details can be described elsewhere. BTW: I consider having an Issue in IZ mandatory as we need to have a reference for cvs commits. Be sure that your "spec" meets the 'three golden rules' which can be used for a review of the "specification" http://wiki.services.openoffice.org/wiki/The_Three_Golden_Rules_for_Writing_OpenOffice.org_Specifications There is nothing "overweight" included and you have to look at these tasks otherwise the integration could (and it will, be sure) fail and will cost others time or break the testing, building or whatever in this case could happen... (3) Get necessary builds (perhaps by using build bots) and hand builds and "spec" over by announcing them somewhere(we must define where!) so that QA, translation and documentation can start working on it. There is already a tool how to announce feature changes: http://eis.services.openoffice.org/ -> Changes mails -> "external" feature or -> "external" API change Then you will find your announcement in allfeatures@openoffice.org and also the QA, DOC etc. will able to find it. - The wording in the menu sould be changed because they have been used 1:1 from Sun's EIS - The announcement can also be written manually but the needed information maybe is missing then... Cu, Jogi -- === Sun Microsystems GmbH Joerg Sievers 20097 Hamburg Quality Assurance Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Michael Meeks wrote: > Hi Mathias, > > On Tue, 2006-11-07 at 19:40 +0100, Mathias Bauer wrote: >> I don't see our discussion related to the way something is implemented, >> so this splitting IMHO is an implicit one. So my idea was (and still is): > > So - the problem is I discern ~no difference at all with what you > detail here and what we have at the moment :-) this doesn't strike me as > in any way improved: Well, I see a big difference to what we *suppose* to have now but I think that you became totally absorbed to some of the terms we use and your own bad experience with it. So I'm fine with leaving them out and I think you will see that we are not much apart. >> step1 - idea: mandatory ;-) >> step2 - create iTeam: optional at this point in time as we can't expect >> it for all community work > > I think having a separate flow for internal Sun people would be better, > rather than cluttering substantially different flows with confusion / > unhelpful terminology IMHO etc. These *are* separate workflows. A Sun engineer would create an iTeam upfront, a community developer would ask for QA and documentation work when he is done with this implementation. I just called this the iTeam but if your prefer we can name it as you did: > post mail to UI/Doc/l10n/project lists with link to > CWS, *minimal* spec. & working build My addition to this would be that an issue should exist and the Project Lead should have been informed until then (the earlier the better) so that he can help to avoid the usual problems mentioned here (not finding QA engineer, no response from UserEx etc.). >> step3 - design/review/implementation cycles: indispensable :-) >> step4 - create iTeam if not done in step2: possible to be done by >> project lead; now mandatory as needed for the next steps > > "create iTeam" is problematic in several ways: > > * it's easy for people in Hamburg > * it is ~impossible for people outside Hamburg. It isn't, but it's harder - that's the reason why I wrote "possible to be done by project lead". > * it is synchronous I don't think so. An asynchronous process it fine for me - but it shouldn't be a "fire and forget". The developer should still feel responsible for his work and so shouldn't rely on others doing the further work for him. > * it implies some 'Team' thing instead of it's real role > which should be one of review / approval. I don't understand this - but perhaps my explanation made my standpoint more clear and your point possibly is now obsolete. > So - what I would like to see: > > + step 1 - create kick-ass feature/tweak/fix for fun > + step 2 - look on IRC for people to discuss with for improvements > => no-one, so on to next step. > + step 3 - write *brief* spec > + step 4 - get build-bot build > + step 5 - post mail to UI/Doc/l10n/project lists with link to > CWS, *minimal* spec. & working build Sounds good and that's more or less what I wanted to describe in less detail ;-). So if you leave the word iTeam out and take it as a variable to be replaced by a number of people doing the UI/Doc/l10n/QA work (though I think that UI problems should have been sorted out before we reach this state). > + the term 'iTeam' doesn't appear, the concept & associated workflow is > nearly antithetical to the sort of iterative, innovation that happens > outside Sun :-) I'm fine with leaving the term "iTeam" out though for me it never was the idea of people sitting together in a room but a group of people assigned to a common goal (to get a feature integrated). It happens in an "asynchronous" style even in Hamburg. So perhaps we can describe it so (with less details ;-): (1) While developing your feature: discuss feature with people on IRC, mailing lists and whatsoever to your liking; it is *recommended* (though not mandatory) to contact the project lead as early as possible and discuss with QA and UserEx also (not to ask for approval but to avoid problems by early contact!). (2) While development happens make sure that at the end you deliver a "spec". This could be just an issue in IZ, a web page or a document, details can be described elsewhere. BTW: I consider having an Issue in IZ mandatory as we need to have a reference for cvs commits. (3) Get necessary builds (perhaps by using build bots) and hand builds and "spec" over by announcing them somewhere(we must define where!) so that QA, translation and documentation can start working on it. (4) React on feedback given by them, be it changing the "spec", fixing a bug etc. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Mathias Bauer <[EMAIL PROTECTED]> writes: > step1 - idea: mandatory ;-) > step2 - create iTeam: optional at this point in time as we can't expect > it for all community work > step3 - design/review/implementation cycles: indispensable :-) > step4 - create iTeam if not done in step2: possible to be done by > project lead; now mandatory as needed for the next steps > step5 - finalize documentation aka "spec" to the necessary degree as > negotiated inside the iTeam; possibly with help from iTeam or Project Lead > step6 - QA, maybe fixing bugs, documentation: how could we do without? ;-) > > Does that make sense? > Hi Mathias, yes, absolutely makes sense. One remark to step4: this is probably our (established devs/Suns) duty, if a patch or CWS comes in from external, to setup the iTeam. Default role to handle this: project leads. Cheers, -- Thorsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Michael Meeks wrote: > Nope, seems a good summary; one of the ideas I came up with was of > splitting the work-flow aspects [ step1: create iTeam, step2: design, > step 3: review, step 4: implement ] etc. from the other pieces that are > necessary for QA / docs / i18n etc. ie. providing separate guidelines > for how teams can function, and develop software vs. what information / > approvals are necessary to get changes included in the product. I don't see our discussion related to the way something is implemented, so this splitting IMHO is an implicit one. So my idea was (and still is): step1 - idea: mandatory ;-) step2 - create iTeam: optional at this point in time as we can't expect it for all community work step3 - design/review/implementation cycles: indispensable :-) step4 - create iTeam if not done in step2: possible to be done by project lead; now mandatory as needed for the next steps step5 - finalize documentation aka "spec" to the necessary degree as negotiated inside the iTeam; possibly with help from iTeam or Project Lead step6 - QA, maybe fixing bugs, documentation: how could we do without? ;-) Does that make sense? Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Joerg Sievers wrote: > Hi Mathias, > > Mathias Bauer wrote: >> Possibly we can establish a process that allows for more "asynchronous" >> work or creates the documentation in a "Q&A" style (QA or documentation >> ask for the information they need instead of forcing the developers to >> provide everything upfront). > > As some of us have desribed in a presentation [1] (slide 12+ is the > i-Team work described -> How to write a specification) held on OOoCon > [2] the i-Team should work together on the specification because they > are the stakeholder for the document. As mentioned in this thread several times it is not possible to expect that contributions from community developers will have an iTeam. We should be able to integrate work done by community developers "to scratch their own itch". In this case the work is done in the way "problem seen - problem fixed - please integrate". I think we should follow this perception by avoiding the "iTeam" term where it isn't mandatory. I understood Michaels idea (that I - und now you - have quoted) in the way that he thinks that in this case where the development is done already when a community developers asks for QA we should think about ways to allow a less formal and Q&A oriented communication between developer and QA or documentation. I think this is a valid request that deserves some thoughts. Please let me repeat the restriction I made in my summary: this should apply to new developers only. If developers would like to continue contributing we should try to get them used to our a little(!) bit more formal working style over time. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Mathias, Mathias Bauer wrote: Possibly we can establish a process that allows for more "asynchronous" work or creates the documentation in a "Q&A" style (QA or documentation ask for the information they need instead of forcing the developers to provide everything upfront). As some of us have desribed in a presentation [1] (slide 12+ is the i-Team work described -> How to write a specification) held on OOoCon [2] the i-Team should work together on the specification because they are the stakeholder for the document. If there are information included in a specification which is not needed by - developer (also developer who will work afterwards with the implementation!) - tester - documentation people then it makes no sense in the document. I hear "lightweight" specification document from many people but mostly I thnk you mean "lightweight specification PROCESS" because in the doucment there should be no information which is not helpful for DEV, QA, DOC! The specification process [3] and issue handling [4] only has been written down and not being changed. If there are intersted people in doing it -> [EMAIL PROTECTED] will be your right place. We want to do it and it should match the needs of DEV, QA, DOC - surely! :-) Have fun, Jogi [1] http://marketing.openoffice.org/ooocon2006/presentations/wednesday_c12.odp [2] http://marketing.openoffice.org/ooocon2006/schedule/community_abstracts.html#c12 [3] http://wiki.services.openoffice.org/wiki/Category:Specification [4] http://qa.openoffice.org/issue_handling/workflowcharts/taskhandling_workflow_feature_specification.html -- === Sun Microsystems GmbH Joerg Sievers 20097 Hamburg Quality Assurance Engineer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] An attempt of a summary: specification process possibilities
Hi Mathias, Sorry - didn't notice your summary before posting mine. OTOH - yours looks rather better than mine, thanks so much for taking the time here. OTOH - I make some more concrete proposals, so perhaps there is some value in discussing both in the same thread. It really helps me to keep at least one of thread-ids or subjects constant wrt. tracking the discussion. > Is that a basis for further considerations? Did I miss > something important? Nope, seems a good summary; one of the ideas I came up with was of splitting the work-flow aspects [ step1: create iTeam, step2: design, step 3: review, step 4: implement ] etc. from the other pieces that are necessary for QA / docs / i18n etc. ie. providing separate guidelines for how teams can function, and develop software vs. what information / approvals are necessary to get changes included in the product. Anyhow - thanks again, Michael. -- [EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] An attempt of a summary: specification process possibilities
Hi together, as I have the feeling that many discussions in our most beloved thread started to go around in circles I want to break out and focus the discussion by providing a personal summary of it. Please read this summary as a whole before you comment on single items, I really tried to cover all points of view, but not in each and every sentence. IMHO the discussion was about "quality" of the producet and it touched two major aspects: - source control - specs and mixed them in a way that many of us talked in cross-purposes. Unfortunately we mixed the spec discussion with the question wether we should throw code in fast or not - and I for myself was jointly responsible for that as I mixed those aspects in one of my first mails. I think that these two topics are only losely coupled and to concentrate on the "spec" discussion we should leave the "integrate early and fast" part out for now. We also touched the matter of "early communication" and it wasn't disproved that early communication is the best way to avoid delayed integration. Also nobody denied that early exchange of ideas is a good thing though that isn't necessary in case of trivial or uncontroversial changes. OTOH it is only fair that contributors trying to get in touch with others can expect a reaction in a reasonable time frame. My personal take on that is that we should track this in the same way as we track response times for patches though I don't want to go too much into details here. But even then we must deal with the situation that something might get stuck and we must avoid that contributions vanish in a black hole. All communication should happen with the spirit "thanks for your work, let me help you get it included" and not "I'm so busy I can't be bothered to reply to your mail/issue". OTOH contributors should accept that they might receive some requests for improvements of their contribution - the more the longer they are "on board". To enable contributors to communicate with others they might need for the integration of their contribution we should have a contact list that makes it easier to find the right people to talk with. Alltogether resolving the communication problems seems to be the most important step towards any possible closer interaction (e.g. specs or iTeams). Now back to specs. "Specs" doesn't necessarily mean exactly what we have now. It can be something more lightweight, but it must be agreed upon by all stakeholders how this should look like. To enable this the stakeholders must publish their goals they connect to "specs". Some of the already mentioned goals are: - helping QA to create and execute test plans - helping documentation to describe the feature - helping developers to implement what the requirement is about (something that usually does not apply to community development as in this case most often the requirement comes from the one who does the implementation) - helping developers to change existing features in a controlled way - to be continued Let's think about "specs" as a kind of documentation that currently has a defined shape but not necessarily must keep this in the future. Whatever shape it will have it must be accessible, understandable and usable for all stakeholders (so it can't be "use the source" :-)). Though nobody of the spec supporters ever made claimed that you can't reach quality without specs as we have them today it was used as a weapon against them. Instead of continuing this endless discussion I would like to propose that we should agree upon this: Specs (not necessarily in their current shape) are a means for achieving quality, but not the only one. It's open for discussion wether the effort/result relation of specs in one or the other shape is fine or not. If we see "specs" as I described them above I think that even those who argue against our current way of doing specs didn't deny that having some kind of spec is a good thing. If we want to change something we must find a replacement for the current process, we must not undermine or ignore it. Whatever we do with specs in the future we should address a lot of problems that have been mentioned: - content can be out of sync with the code - missing content - broken or unaccessible links - maintainability of screenshots (embedded/linked?) - maintainability of localized strings - uncontroversial and trivial changes should go in fast and easy - non-responsiveness of people shouldn't block contributions: ensure that the spec. process is filled with shortish timeouts to handle people that don't respond - make every possible step asynchronous so there are as few round-trips as humanly possible - separate the aspects of design requirements (team) and documentation (spec) and make it less formal - focus the saving in (very scarce) developer / QA resource on other things: a good unit test framework eg. (*) - re-direct some spec. process time in favour of peer code review - it will yield a higher quality, and ultimately be
