Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[BWS Johnson]

Salvete!


>>
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.

>>

It's obvious to me how much work you're putting in Jonathan, and I 
appreciate it. Thank you. I'm glad one of your big goals is to recruit new 
people since if Koha were a kid, it would be old enough to drive in the USA.


>>
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.

>>

Yes.


>>
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).

>>

Thank you for clarifying this. I wasn't sure whether it would eventually 
supercede BZ or not.

Cheers,
Brooke
___
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/

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[Jonathan Druart]

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  wrote:

> Hi
>
> On Wed, Aug 9, 2017 at 7:25 PM, Jonathan Druart
>  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
>
___
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/

Re: [Koha-devel] MARC frameworks in Koha

[Katrin]

I can't think of something better for now, thx for finding out and 
explaining!



On 10.08.2017 10:33, Marcel de Rooy wrote:


> Christopher got me thinking: For 260 and 264 are repeatable, as a side 
effect of cataloguing rule changes, they might even appear both in a 
record (even if they shouldn't). Which year will be given priority? 
For display purposes in the brief views, only one year should be 
displayed.


TransformMarcToKoha already picks the first year from copyrightdate; 
this is not changed. In the new code it will handle fields sorted by 
tag. So 260 will be handled before 264. Within the same tag, it will 
handle fields based on their order in the MARC record itself. With 
1950 in field 260 and 1960 in field 264, a string results like ‘1950 | 
1960’. In case of copyrightdate the current logic of picking the first 
year (from 260 in this example) will be applied. So returning 1950. I 
assume that the example of a 260 and a 264 is rare, but I can imagine 
that there are multiple 264s in a RDA record. In that case it depends 
on the order of the 264s in the MARC.




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

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[Jon Knight]

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

Re: [Koha-devel] MARC frameworks in Koha

[Marcel de Rooy]

> Christopher got me thinking: For 260 and 264 are repeatable, as a side effect 
> of cataloguing rule changes, they might even appear both in a record (even if 
> they shouldn't). Which year will be given priority? For display purposes in 
> the brief views, only one year should be displayed.

TransformMarcToKoha already picks the first year from copyrightdate; this is 
not changed. In the new code it will handle fields sorted by tag. So 260 will 
be handled before 264. Within the same tag, it will handle fields based on 
their order in the MARC record itself. With 1950 in field 260 and 1960 in field 
264, a string results like ‘1950 | 1960’. In case of copyrightdate the current 
logic of picking the first year (from 260 in this example) will be applied. So 
returning 1950. I assume that the example of a 260 and a 264 is rare, but I can 
imagine that there are multiple 264s in a RDA record. In that case it depends 
on the order of the 264s in the MARC.
___
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/