FW: Code simplicity document
Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? imo we need some more structure at the signoff side. We have the Bugzilla categories that define the default assignment for a new bug. Would it be useful to assign a default signer per category too? Such assignments could be evaluated regularly to see if they still work. Marcel ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Paul Poulain [paul.poulain@biblibre.com] Verzonden: maandag 9 mei 2011 15:46 Aan: koha-devel@lists.koha-community.org Onderwerp: [Koha-devel] Document to read Hello, chris gave this url on IRC, I think it's worth sharing : http://www.codesimplicity.com/post/open-source-community-simplified/ it's a great document. I think it's worth asking ourself : "what are we doing well, what could we improve" This question is specifically sent to new contributors: what did we well, what could be improve for new/future newbies ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I too enjoyed this article and took note of this and saw during the IRC meeting a comment about after a release how the community drops off. "In the past, before a major release, we would “freeze” the trunk. This meant that no new features could be developed for several weeks or months until we felt that trunk was stable enough to call a “release candidate.” Then we would create a new stable branch from the trunk and re-open the main-line trunk for features. However, while trunk was frozen, there was no feature development happening *anywhere* in the Bugzilla Project. Graph analysis showed *very clearly* that every time we would freeze, the community would shrink drastically and it would take *several months* after we un-froze for the size of the community to recover. It happened uniformly, every single time we would freeze, over many years and many releases." - Quote from "Open source simplified, read today 05/11/2011 - at URL - http://www.codesimplicity.com/post/open-source-community-simplified/ David Schuster On Wed, May 11, 2011 at 7:19 AM, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>wrote:
Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? imo we need some more structure at the signoff side. We have the Bugzilla categories that define the default assignment for a new bug. Would it be useful to assign a default signer per category too? Such assignments could be evaluated regularly to see if they still work.
Marcel ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [ koha-devel-bounces@lists.koha-community.org] namens Paul Poulain [ paul.poulain@biblibre.com] Verzonden: maandag 9 mei 2011 15:46 Aan: koha-devel@lists.koha-community.org Onderwerp: [Koha-devel] Document to read
Hello,
chris gave this url on IRC, I think it's worth sharing : http://www.codesimplicity.com/post/open-source-community-simplified/
it's a great document. I think it's worth asking ourself : "what are we doing well, what could we improve"
This question is specifically sent to new contributors: what did we well, what could be improve for new/future newbies ?
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- David Schuster Plano ISD Library Technology Coordinator
Graph analysis showed very clearly that every time we would freeze, the community would shrink drastically and it would take several months after we un-froze for the size of the community to recover
Sure, because fixing bugs is very unsexy. It's great to get all the feature contributions before a feature freeze, but I wish it was as easy to get people to fix bugs. It's a shame, because while contributing features may be more fun for an experienced developer, fixing a bug is probably the best way for a newcomer to the community to get a foot in the door. The complexity of bugs varies, but there are always a few which are minor enough to be tackled by a newbie. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On 12 May 2011 00:19, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature?
Unfortunately that has always been the case since we moved to the workflow of having patches. The new statuses and reports showing bugs waiting for sign off have I think made it less likely. For 3.4.0 for example there were over 1000 patches, from 66 different people in 6 months that made it in. So I think we are slowly improving all the time, and should strive to continue to do so. Currently now the best way of getting a patch signed off, is asking someone to look at it.
imo we need some more structure at the signoff side. We have the Bugzilla categories that define the default assignment for a new bug. Would it be useful to assign a default signer per category too? Such assignments could be evaluated regularly to see if they still work.
This is also not a new idea, for a long time now we have been trying to get people to volunteer to 'own' a section of Koha. IE someone volunteer to look after circulation, someone else the opac, someone else xslt etc. So far without success, I'd love for this to happen though :) Chris
On 12 May 2011 00:19, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? Unfortunately that has always been the case since we moved to the workflow of having patches. The new statuses and reports showing bugs waiting for sign off have I think made it less likely. For 3.4.0 for example there were over 1000 patches, from 66 different people in 6 months that made it in. So I think we are slowly improving all the time, and should strive to continue to do so.
Currently now the best way of getting a patch signed off, is asking someone to look at it. Jumping in the discussion: the workflow is great, in theory. But when no-one find time to sign-off a patch, it results in patches being lost in limbo. And when someone suddenly takes care, unfortunatly,
Le 11/05/2011 16:22, Chris Cormack a écrit : the patch does not apply anymore, so the patch writter has to rebase,... It not a good method to motivate ppl to contribute, obviously ! At the moment, we have 140 patches waiting for sign-off. Some including critical bugs. Just picking one of them: 5995 = It requires a CAS server to be tested, and I fear no-one has one. I can guarantee that the problem has been reported by a library using Koha. I can guarantee this is the patch we've applied, and the library has closed the bug on our internal platform. I can guarantee that this is exactly the patch we've made. And I can guarantee the library will never sign-off anything. So ... we're waiting for someone to sign-off this patch. And I feel we'll wait for a long time. Another example: 3652 (XSS vulnerabilities) I could add that many features we've submitted still have not made their way into Koha master, and it's not because of our efforts, it's because of this too strong workflow. They're too complex to apply/test/sign for someone not able to dedicate a full day to this task. But, once again, those features are working well for our customers, but they'll never sign-off anything ! Chris, I know we disagree here. But the workflow would be a good one if we had a long list of developers available, and we don't have. What's the solution ? I already have proposed, at the beginning of 3.4, to have pending features merged "immediatly", to let ppl (including librarians) time to do QA. You rejected this idea. I make it again : I think we should have a small time of, say, 2 months, where new features will be included easily. With a sandbox setup for anyone to test them (i'm definetly sure I could motivate french librarians to test. I'll never succeed to make them sign-off !). And during the 4 remaining months, 1- fix bugs on merged features (and even revert some if needed, like no feedback from the dev and big problems), 2- add features after a strong patch workflow. To summarize : T+0 - T+60 = any feature/patch that applies and is sent cleanly by a contributor that can promize he will take care of problems on the feature are merged T+60- T+150 = features/patches added only after a standard QA/signoff (i'm not sure i'm happy with a 1signoff+1QA barrier, I fear it's too high, but...) T+150 - T+180 = features & string freeze Without this, I think/feel that the "140" patches waiting for signoff will never be lowered. 15 persons worked for one full week during hackfest, and after 1 months, we're back to a number I consider as huge. PS : challenge: who is interested in signing BZ6328 i just submitted ? I feel no-one, as it's related to fines in days, and it seems it's something strange to US/NZ and many countries. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul, I agree that having 140 patches needing signoff is way too many; I'd like to see all them signed off and ready for QA. Lots of good stuff out there, and if it's not being integrated, we're losing out. However, the workflow is a good one from a quality assurance point of view. Someone writes the code, someone else confirms it applies and seems to solve the bug, then QA checks for integration with all other aspects of Koha (so adding something new doesn't break something else), and finally the RM pushes it. As an internal measure, we at ByWater started signing off on all our out-going patches before putting them on the list. The idea here was just make sure we were putting out code free of typos, silly errors and the like (I've been known to make such mistakes, and loved having another set of eyes in the company check things before I publicly released them). We found that for Koha 3.4, that was often enough of a sign-off to get things committed. I was concerned that since it was "in company", the signoff would be less, and for larger, deeper devs, perhaps it is, but for many of the bugfixes it was sufficient. So, code that one of the BibLibre team has written could be signed off on by any other member of the company, and that would advance the status. Anything that's in the SIGNED_OFF state is in my queue for QA. The signoffs can come from anyone, even within a company; I'll still be doing rigourous testing. I'll factor in the sign-offs, especially for things like CAS that I don't have the services to test with right now, but I don't want to do any blind signing off, or pushing things that need followup patches to complete them (because what if THOSE never get their signoff, and we reach release time?). Once the SIGNED_OFF list is exhausted, I'll start selecting from the NEEDS_SIGNOFF pool, and putting those through QA, as time permits. SIGNED_OFF will take priority, but this will provide a way to keep things flowing if folks aren't doing signoffs as fast as I'm doing QA. I hope this helps elucidate where I'm looking to go with this workflow and how we can work to get it flowing along. Cheers, -Ian On Wed, May 11, 2011 at 11:22 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
On 12 May 2011 00:19, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending
It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? Unfortunately that has always been the case since we moved to the workflow of having patches. The new statuses and reports showing bugs waiting for sign off have I think made it less likely. For 3.4.0 for example there were over 1000 patches, from 66 different people in 6 months that made it in. So I think we are slowly improving all the time, and should strive to continue to do so.
Currently now the best way of getting a patch signed off, is asking someone to look at it. Jumping in the discussion: the workflow is great, in theory. But when no-one find time to sign-off a patch, it results in patches being lost in limbo. And when someone suddenly takes care, unfortunatly,
Le 11/05/2011 16:22, Chris Cormack a écrit : patches. the patch does not apply anymore, so the patch writter has to rebase,... It not a good method to motivate ppl to contribute, obviously !
At the moment, we have 140 patches waiting for sign-off. Some including critical bugs.
Just picking one of them: 5995 = It requires a CAS server to be tested, and I fear no-one has one.
I can guarantee that the problem has been reported by a library using Koha. I can guarantee this is the patch we've applied, and the library has closed the bug on our internal platform. I can guarantee that this is exactly the patch we've made. And I can guarantee the library will never sign-off anything. So ... we're waiting for someone to sign-off this patch. And I feel we'll wait for a long time.
Another example: 3652 (XSS vulnerabilities)
I could add that many features we've submitted still have not made their way into Koha master, and it's not because of our efforts, it's because of this too strong workflow. They're too complex to apply/test/sign for someone not able to dedicate a full day to this task. But, once again, those features are working well for our customers, but they'll never sign-off anything !
Chris, I know we disagree here. But the workflow would be a good one if we had a long list of developers available, and we don't have.
What's the solution ? I already have proposed, at the beginning of 3.4, to have pending features merged "immediatly", to let ppl (including librarians) time to do QA. You rejected this idea.
I make it again : I think we should have a small time of, say, 2 months, where new features will be included easily. With a sandbox setup for anyone to test them (i'm definetly sure I could motivate french librarians to test. I'll never succeed to make them sign-off !). And during the 4 remaining months, 1- fix bugs on merged features (and even revert some if needed, like no feedback from the dev and big problems), 2- add features after a strong patch workflow.
To summarize : T+0 - T+60 = any feature/patch that applies and is sent cleanly by a contributor that can promize he will take care of problems on the feature are merged T+60- T+150 = features/patches added only after a standard QA/signoff (i'm not sure i'm happy with a 1signoff+1QA barrier, I fear it's too high, but...) T+150 - T+180 = features & string freeze
Without this, I think/feel that the "140" patches waiting for signoff will never be lowered. 15 persons worked for one full week during hackfest, and after 1 months, we're back to a number I consider as huge.
PS : challenge: who is interested in signing BZ6328 i just submitted ? I feel no-one, as it's related to fines in days, and it seems it's something strange to US/NZ and many countries.
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
But when no-one find time to sign-off a patch, it results in patches being lost in limbo. And when someone suddenly takes care, unfortunately, the patch does not apply anymore, so the patch writer has to rebase,...
Yes, and that's why we should all be maintaining our own git branches for any patch which we've submitted but which hasn't been accepted. It's up to each of us to rebase these branches frequently to make sure they still apply and to resubmit patches when necessary. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Wed, 11 May 2011 17:22:15 +0200, Paul Poulain <paul.poulain@biblibre.com> wrote:
PS : challenge: who is interested in signing BZ6328 i just submitted ? I feel no-one, as it's related to fines in days, and it seems it's something strange to US/NZ and many countries.
I'll be happy to signoff that one since we also use fine in days here in Argentina. Off course, once we fix the stuff I reported yesterday. However I agree that the signoff process needs to be relaxed a little. I'm very new here and I've seen devs reworking on an already fixed bug because it doesn't apply anymore, because nobody signed-it-off on time. Currently it's hard for some developers to signoff something they don't care about. Trivial stuff, ok, but what if you need a more complicated setup than usual? We can use other ideas in conjunction as well, like having assigned people to sign off each area. I'll contribute one another: to have sign-off fests every now and then. Maybe once/twice a month? -- Fernando Canizo (a.k.a. conan) - http://conan.muriandre.com/ GCS d? s:+ a C++ P--- L++++ E--- W+++ w--- M-- PE-- !tv b+++ h---- y+++
participants (7)
-
Chris Cormack -
David Schuster -
Fernando L. Canizo -
Ian Walls -
Marcel de Rooy -
Owen Leonard -
Paul Poulain