As written in it, without an agreement we will find all together, no new enhancements are going

to be pushed.

I am not sure which 'agreement' you are seeking here. The time for a critical bug to become part of master, just depends on involvement of people and the publicity made for it via IRC and mailing lists. If it takes more time, nobody should complain, because we can all participate. But the approach of vetoing enhancements is imo contraproductive and will only scare people away. So I just hope that you change your mind about that course. We cannot force people to participate. If you are not pushing enhancements btw, it does not make much sense to QA them too. Same for testing or signing them off. Note if we pile up everything in PQA, we will have a lot of rebasing and we will create some new bugs in that process. Marcel

On Wed, 9 Aug 2017, Jonathan Druart wrote:

If you are a developer and you want to help, what do you do? Where do you do? How to you prioritize your work? Are you all picking bugs randomly in the queue?

I'm not a "developer" in that I don't work for a commercial Koha support company, but as our library are moving to Koha and I'm a coder, I've been dipping my toes in the Koha dev waters. As such, Koha is only a very small part of my day job, so doesn't get lots of time allocated to it at the moment. Running to jump on the Koha dev train is quite a challenge: there's much to learn and the information about what to do and what is required/optional takes a while to find. As such I currently feel much happier/safer making small enhancements/bug fixes than working on show stopping blockers where I may well currently lack the skills and knowledge to do the right thing. So for me, yes, I do tend to look at Bugzilla bugs randomly in the queue, as some are of more interest to our library than others (and quite a few I don't understand and/or seem to have grown crufty and unusable). If I get a spare few minutes and something interesting pops up on the IRC channel or the mailing list I may look at it.

We need to all agree on a "place to go" to know what need to be done. I listed ideas.

For what its worth, I'd suggest just having "a" place to go. Koha seems to have lots of places to go at the moment (IRC, mailing list, Kanban, bugzilla, wiki pages, random people's githubs, etc, etc). If you're suffering from a lack of attention, focus what attention there is on just one place, and don't introduce more ways of interacting. Jon

Hi Indranil, Of course I was not talking about new contributors. My main goal for this release is to help new people to come on-board. We refreshed the wiki, wrote a step-by-step how-to "signoff and write patches", etc. I give personal answers to new contributors, guide them, give them quick and early feedbacks on their patches in order to keep them motivated. This button I am asking for is to alert support companies and regular developers that something is (very) urgent and need their attention. I would like to stop gesticulating to try getting this attention. I would like a button I can push to make a red blinking light on some desks. Then everybody is free to ignore it, but they saw it and I will not push it again. It will be easier for me to know that people knows, than sending emails, pinging on #koha, adding card to the kanban, CCing people on the bug report, without never knowing if they are aware of the problem. About the kanban: its goal is NOT to replace bugzilla, it has never been and will never be. We are talking about two different tools. One is a bug tracker, the other one is a tool to manage/prioritize different tasks, group them under "Epic" (big works), form working groups, etc. Moreover community tasks are not always one entry in bugzilla, we want to track, discuss and keep history of more stuffs than just bugs. Taiga answered this lack. Please re-read the wiki page of the kanban if its goal is not clear (or ask me to update it). Cheers, Jonathan On Thu, 10 Aug 2017 at 06:43 Indranil Das Gupta <indradg@gmail.com> wrote:

Hi

On Wed, Aug 9, 2017 at 7:25 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:

...

I do not see the point to sign-off and QA trivial string patches when blockers are in the queue for weeks (no need to tell me everybody does what do they want, I still agree with that).

I completely get that blockers need to be sorted out. But personally I got into Koha dev stream with string patches. How to write the tests was a mystery to me in the initial days and I was afraid to get in there. And when I did, I made mistakes which others helped clean up and that's how I learnt and I'm still learning.

For a newbie, seeing their trivial patch being signed off and pushed is a shot of adrenaline and it gives them the confidence to bite into bigger pieces. I'm sure that we do not want Koha development to be seen as an oligarchy of expert devs, by not pushing the insignificant patches when there are blocker patches, especially when there is a call up for more "hands on the deck".

Personally I was *not* happy with the shift to taiga. I knew my way around BZ. Kanban was a new format to me and having to spend time to learn a new pm tool was something that had me dragging my feet. But then its human nature.to resist change. :-) I will probably just get used to it in bit

just my 2c

indranil

-- Indranil Das Gupta L2C2 Technologies

Phone : +91-98300-20971 <+91%2098300%2020971> WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

I have Arduinos and Raspberry Pis at my desk. Maybe making a literal big red warning light isn’t a bad idea… ;). We could call it “The Bug Signal” after The Bat Signal. We could make a Kickstarter! I’m joking about the Kickstarter, but I kind of like the idea of a little physical Koha bug display :p. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Jonathan Druart Sent: Friday, 11 August 2017 1:14 AM To: Indranil Das Gupta <indradg@gmail.com> Cc: Koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] FW: Where is the BIG RED WARNING button? Hi Indranil, Of course I was not talking about new contributors. My main goal for this release is to help new people to come on-board. We refreshed the wiki, wrote a step-by-step how-to "signoff and write patches", etc. I give personal answers to new contributors, guide them, give them quick and early feedbacks on their patches in order to keep them motivated. This button I am asking for is to alert support companies and regular developers that something is (very) urgent and need their attention. I would like to stop gesticulating to try getting this attention. I would like a button I can push to make a red blinking light on some desks. Then everybody is free to ignore it, but they saw it and I will not push it again. It will be easier for me to know that people knows, than sending emails, pinging on #koha, adding card to the kanban, CCing people on the bug report, without never knowing if they are aware of the problem. About the kanban: its goal is NOT to replace bugzilla, it has never been and will never be. We are talking about two different tools. One is a bug tracker, the other one is a tool to manage/prioritize different tasks, group them under "Epic" (big works), form working groups, etc. Moreover community tasks are not always one entry in bugzilla, we want to track, discuss and keep history of more stuffs than just bugs. Taiga answered this lack. Please re-read the wiki page of the kanban if its goal is not clear (or ask me to update it). Cheers, Jonathan On Thu, 10 Aug 2017 at 06:43 Indranil Das Gupta <indradg@gmail.com <mailto:indradg@gmail.com> > wrote: Hi On Wed, Aug 9, 2017 at 7:25 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org <mailto:jonathan.druart@bugs.koha-community.org> > wrote:

I do not see the point to sign-off and QA trivial string patches when blockers are in the queue for weeks (no need to tell me everybody does what do they want, I still agree with that).

I completely get that blockers need to be sorted out. But personally I got into Koha dev stream with string patches. How to write the tests was a mystery to me in the initial days and I was afraid to get in there. And when I did, I made mistakes which others helped clean up and that's how I learnt and I'm still learning. For a newbie, seeing their trivial patch being signed off and pushed is a shot of adrenaline and it gives them the confidence to bite into bigger pieces. I'm sure that we do not want Koha development to be seen as an oligarchy of expert devs, by not pushing the insignificant patches when there are blocker patches, especially when there is a call up for more "hands on the deck". Personally I was *not* happy with the shift to taiga. I knew my way around BZ. Kanban was a new format to me and having to spend time to learn a new pm tool was something that had me dragging my feet. But then its human nature.to <http://nature.to> resist change. :-) I will probably just get used to it in bit just my 2c indranil -- Indranil Das Gupta L2C2 Technologies Phone : +91-98300-20971 <tel:+91%2098300%2020971> WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net <http://irc.freenode.net> Twitter : indradg

Hi all, I like Magnus' suggestion of using the Dashboard. I look at it often and it's usually my starting point before signing off patches. Now with Jenkins status being back on it, it's even more useful for me RMaint. Maybe we could add a section for the RM to post urgent messages? Most of the Dashboard is data pulled in from difference sources, not sure how to best add it to it. Katrin On 11.08.2017 11:03, Magnus Enger wrote:

Kia ora!

I agree that there should be *one* place to get an overview of the health of the project and what needs doing (at least as far as bugs go), and for me the natural place for that is the dashboard: http://dashboard.koha-community.org/

We could probably do more with that, and the data behind it (from Bugzilla). Like: - display blockers/critical bugs in big red letters across the top. (Or use tags to let the RM choose bugs that should be specially highlighted.) - make the favicon red when there are such blockers (developers could have the dashboard always open in a pinned tab) - highlight the people who helped signoff and qa those critical patches

As for what to work on and when: With a lot more customers there is a lot less time to sign off patches. So if I am going to do it I need to find one that - fits in the time I have available - is relevant to my customers - is in a part of Koha I know, or it will take a lot more time (signing off patches in unknown parts of Koha is great for learning, of course, but it will take more time)

Just my NOK 0,02.

Best regards, Magnus Libriotech

On 11 August 2017 at 02:01, David Cook <dcook@prosentient.com.au> wrote:

...

I have Arduinos and Raspberry Pis at my desk. Maybe making a literal big red warning light isn’t a bad idea… ;). We could call it “The Bug Signal” after The Bat Signal. We could make a Kickstarter!

I’m joking about the Kickstarter, but I kind of like the idea of a little physical Koha bug display :p.

David Cook

Systems Librarian

Prosentient Systems

72/330 Wattle St

Ultimo, NSW 2007

Australia

Office: 02 9212 0899

Direct: 02 8005 0595

From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Jonathan Druart Sent: Friday, 11 August 2017 1:14 AM To: Indranil Das Gupta <indradg@gmail.com> Cc: Koha-devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

Hi Indranil,

Of course I was not talking about new contributors. My main goal for this release is to help new people to come on-board.

We refreshed the wiki, wrote a step-by-step how-to "signoff and write patches", etc.

I give personal answers to new contributors, guide them, give them quick and early feedbacks on their patches in order to keep them motivated.

This button I am asking for is to alert support companies and regular developers that something is (very) urgent and need their attention. I would like to stop gesticulating to try getting this attention. I would like a button I can push to make a red blinking light on some desks. Then everybody is free to ignore it, but they saw it and I will not push it again. It will be easier for me to know that people knows, than sending emails, pinging on #koha, adding card to the kanban, CCing people on the bug report, without never knowing if they are aware of the problem.

About the kanban: its goal is NOT to replace bugzilla, it has never been and will never be.

We are talking about two different tools. One is a bug tracker, the other one is a tool to manage/prioritize different tasks, group them under "Epic" (big works), form working groups, etc. Moreover community tasks are not always one entry in bugzilla, we want to track, discuss and keep history of more stuffs than just bugs. Taiga answered this lack. Please re-read the wiki page of the kanban if its goal is not clear (or ask me to update it).

Cheers,

Jonathan

On Thu, 10 Aug 2017 at 06:43 Indranil Das Gupta <indradg@gmail.com> wrote:

Hi

On Wed, Aug 9, 2017 at 7:25 PM, Jonathan Druart <jonathan.druart@bugs.koha-community.org> wrote:

...

I do not see the point to sign-off and QA trivial string patches when blockers are in the queue for weeks (no need to tell me everybody does what do they want, I still agree with that). I completely get that blockers need to be sorted out. But personally I got into Koha dev stream with string patches. How to write the tests was a mystery to me in the initial days and I was afraid to get in there. And when I did, I made mistakes which others helped clean up and that's how I learnt and I'm still learning.

For a newbie, seeing their trivial patch being signed off and pushed is a shot of adrenaline and it gives them the confidence to bite into bigger pieces. I'm sure that we do not want Koha development to be seen as an oligarchy of expert devs, by not pushing the insignificant patches when there are blocker patches, especially when there is a call up for more "hands on the deck".

Personally I was *not* happy with the shift to taiga. I knew my way around BZ. Kanban was a new format to me and having to spend time to learn a new pm tool was something that had me dragging my feet. But then its human nature.to resist change. :-) I will probably just get used to it in bit

just my 2c

indranil

-- Indranil Das Gupta L2C2 Technologies

Phone : +91-98300-20971 WWW : http://www.l2c2.co.in Blog : http://blog.l2c2.co.in IRC : indradg on irc://irc.freenode.net Twitter : indradg

_______________________________________________ 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/

+1 for improving the dashboard +1 a place for Release Manager warnings, notices. requests...etc 2017-08-11 11:55 GMT+02:00 Marcel de Rooy <M.de.Rooy@rijksmuseum.nl>:

+1 for improving the dashboard

Instead of listing the oldest bugs, which may not be that interesting, we should list the critical ones on top. The need to click on that line should be removed. See them rightaway. Maybe we can put these oldies somewhere down on the page in order to not forget them?

_______________________________________________ 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/

Sorry for the empty message... What I wanted to say: +1 for improving the dashboard (I always check the dashboard first, then the Bug tracker, then the list of bugs to sign off, then my open bugs...) Maybe the Dashboard could contain the links to the newest bugs / changed bugs from the Bug trackers start page: Bugs reported in the last 24 hours | last 7 days Bugs changed in the last 24 hours | last 7 days Marc Am 11.08.2017 um 15:34 schrieb Marc Véron:

Am 11.08.2017 um 11:55 schrieb Marcel de Rooy:

...

+1 for improving the dashboard

Instead of listing the oldest bugs, which may not be that interesting, we should list the critical ones on top. The need to click on that line should be removed. See them rightaway. Maybe we can put these oldies somewhere down on the page in order to not forget them?

_______________________________________________ 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/

+1 to all of this. Brooke From: Gaetan Boisson <gaetan.boisson@biblibre.com> To: koha-devel@lists.koha-community.org Sent: Monday, August 21, 2017 5:59 AM Subject: Re: [Koha-devel] FW: Where is the BIG RED WARNING button? I really understand Jonathan's point here. He's probably become the one contributor with the best overall vision of the project now. I really like the idea of using the dashboard more and making it better. I also think Jonathan might need something more proactive, the dashboard requires the contributors to look at it and decide for themselves, but everyone is really busy, and we all get to make our own choices regarding priorities. Two ideas i would suggest (sorry if it's redundant or has been said before): - why not have a "mission critical" meeting from time to time for this kind of issues? With the goal of defining precisely who will do what on a given issue? - would a small team of designated people help? A sort of Koha Kommando Jonathan can rely on when stumbling on something like this? It would need to be used carefully obviously, but i think just calling for help on the mailing list, irc or the dashboard dilutes the feeling of emergency, because no one is explicitly in charge. Maybe we (BibLibre), and other import support companies like Bywater and others can commit to having one person that is part of the emergency team? (note that I'm writing all this without having mentioned it to anyone at BibLibre...) https://youtu.be/_MVonyVSQoM Would that help? Le 11/08/2017 à 15:40, Marc Véron a écrit : Sorry for the empty message... What I wanted to say: +1 for improving the dashboard (I always check the dashboard first, then the Bug tracker, then the list of bugs to sign off, then my open bugs...) Maybe the Dashboard could contain the links to the newest bugs / changed bugs from the Bug trackers start page: Bugs reported in the last 24 hours   | last 7 days  Bugs changed in the last 24 hours   | last 7 days   Marc Am 11.08.2017 um 15:34 schrieb Marc Véron: Am 11.08.2017 um 11:55 schrieb Marcel de Rooy: <!--#yiv0538640299 P {margin-top:0;margin-bottom:0;}--> +1 for improving the dashboard Instead of listing the oldest bugs, which may not be that interesting, we should list the critical ones on top. The need to click on that line should be removed. See them rightaway. Maybe we can put these oldies somewhere down on the page in order to not forget them? _______________________________________________ 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/ _______________________________________________ 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/ -- Gaetan Boisson Chef de projet bibliothécaire BibLibre +33(0)6 52 42 51 29 108 rue Breteuil 13006 Marseille gaetan.boisson@biblibre.com _______________________________________________ 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/

Salvete! Crazy idea: Most of our developers have been at this a while. They've submitted a lot of patches. Is there anyone with a machine learning knack that could apply ML in such a way to suggest a next patch for developers based on their prior submissions? Cheers, Brooke