Open Space

[sebas5384]

Descrição: Eu participo de eventos de Ágil, e por causa da cultura do próprio ágil, a auto organização é protagonismo é muito incentivado na comunidade. Isso traz muita inovação e mantém a comunidade mais unida, facilitando a comunicação com interesses em comum entre os participantes do evento.

Quando fui no último BrazilJS eu estava com a expectativa de trocar experiências sobre Programação Funcional (que é um assunto que eu gosto muito) e mesmo tendo ido com um grupo de amigos, mas não consegui conversar com (quase) ninguém sobre isso, o que gerou uma certa frustração.

Então quando vi o @jaydson passando, sugeri realizar um Open Space no próximo ano, para ter uma participação maior das pessoas que vão pro evento, e não só os palestrantes, já que ninguém vai ficar perguntando pessoa por pessoa se quer falar sobre um assunto específico, rsrs.

Tem muito material por ai sobre como fazer, mas como eu já tenho experiência posso resumir rapidamente:

• Os participantes do evento criam post-its com o assunto.
• Assim que forem criados os assuntos também se realiza a votação colocando pontinhos (pode ter um limite) em cada post-it indicando interesse.
• Em determinado momento se separam os assuntos mais votados (pode ter um limite de assuntos).
• Cada assunto será espalhado pelo salão ou área do evento.
• Quem sugeriu o assunto pode começar a conversa.
• As pessoas interessadas se movimentam pelo salão procurando o assunto que mais lhe interessa e podem participar abertamente, pois não é uma participação de expectador.

A dinâmica pode levar até 1h e o esforço de organização + operação é relativamente baixo.

Link: Wikipédia: https://pt.wikipedia.org/wiki/Espa%C3%A7o_aberto Slides: http://pt.slideshare.net/giselakassoy/open-space-27783854

[codecov[bot]]

Codecov Report

Merging #184 into master will decrease coverage by 0.13%. The diff coverage is 87.50%.

@@            Coverage Diff             @@
##           master     #184      +/-   ##
==========================================
- Coverage   91.64%   91.50%   -0.14%     
==========================================
  Files           8        8              
  Lines         682      789     +107     
==========================================
+ Hits          625      722      +97     
- Misses         57       67      +10     

Impacted Files	Coverage Δ
src/ColorTypes.jl	100.00% <ø> (ø)
src/conversions.jl	67.39% <50.00%> (ø)
src/types.jl	90.38% <87.50%> (-0.49%)	:arrow_down:
src/traits.jl	95.43% <90.90%> (-0.81%)	:arrow_down:
src/operations.jl	100.00% <100.00%> (ø)
src/show.jl	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 4bb8aa9...e0b9e89. Read the comment docs.

[kimikage]

I'm mostly in favor of it. :+1: However, I do not feel comfortable with the gradual transition without a determinate goal. I'm against using methods such as eltypec and lengthc, i.e. using API changes as "notifications". So, we should design a new API for treating color components, instead of "renaming".

[kimikage]

BTW, when implementing ColorBlendModes, I realized that simple iterators are not very useful other than with RGB colors. For example, the hue is cyclic and not normalized to [0,1], and in Lab and Luv spaces, L is a non-negative number, but a, b, u and v can be both positive and negative. And the alpha is clearly a foreign component as a color component.

[timholy]

However, I do not feel comfortable with the gradual transition without a determinate goal. I'm against using methods such as eltypec and lengthc, i.e. using API changes as "notifications".

Not entirely sure I understand your meaning. Two stated goals might be (1) to ensure we never treat colorants like containers, or (2) to make colorants behave like numbers wrt the iterator interface. (2) probably requires (1) so it is the more stringent goal (and I'm not sure we want to support iterate at all).

However, the operation performed by eltypec (extract the numeric type) is certainly useful, independent of what you call it.

EDIT: or are you saying that by not supporting iterate and the iteration traits, it's essentially OK that we currently use eltype and length? (i.e., that the status quo is actually OK.) There is genuine merit in that viewpoint, and I am willing to be persuaded that we're doing pretty well currently and don't need to make this change.

[kimikage]

I apologize for my poor explanation. I was envisioning a slightly longer term goal, i.e. whether ColorTypes or its add-on provides an API set for treating colorants as containers.

I think that (1) and (2) are appropriate as subgoals. Perhaps the meaning of those subgoals depends on the long-term goal.

However, the operation performed by eltypec (extract the numeric type) is certainly useful, independent of what you call it.

That’s exactly what I was thinking. Since it is useful, I don't think we should give it a name that is reminiscent of eltype. Or, if we want it to look like eltype, it should definitely be eltype (and we will introduce iterator-like or view-like interfaces).

BTW,

julia> real(Complex{Float32})
Float32

So, should red(RGB{Float32}) and comp1(RGB{Float32}) return Float32? I feel them a bit strange, but they will support the reasonableness of a new method named component or componentof,

[johnnychen94]

Except for the conceptual purity, My limited understanding couldn't come up with a case that could be done more intuitively and/or concisely compared to the status quo. I'm sold if there's such one.

[kimikage]

As mentioned in https://github.com/JuliaGraphics/ColorTypes.jl/issues/167#issuecomment-593042392, I think that it might be nice that color types can be like tuples in the "future". In other words, I think it is a too strong constraint that all components must be of the same type. For example, it makes a trouble with RGB565/RGB332 (cf #114, #115). Some graphics software and image formats encode Lab/YCbCr-like colors as {Normed, Fixed, Fixed}.

Therefore, I think it is a good idea to use this as an opportunity to create an API which assumes that the type of each component can be different, even if we support only homogeneous color types for the time being.

In that sense, I don't think there is a reason to merge this PR immediately.

or are you saying that by not supporting iterate and the iteration traits, it's essentially OK that we currently use eltype and length? (i.e., that the status quo is actually OK.)

This is not the essence of my idea, but the answer is "yes".:smile:

[timholy]

One option to support iteration is a function channels(c) that returns a tuple. Probably an important rule would be typeof(c)(channels(c)...,) === c.

[kimikage]

By the way, ImageCore.jl defines an internal function named tuplify.

tuplify(c::Color1) = (comp1(c),)
tuplify(c::Color3) = (comp1(c), comp2(c), comp3(c))
tuplify(c::Color2) = (comp1(c), alpha(c))
tuplify(c::Color4) = (comp1(c), comp2(c), comp3(c), alpha(c))

https://github.com/JuliaImages/ImageCore.jl/blob/3beb2226dce03cdc505cca6d6ce6dc1626b533b1/src/colorchannels.jl#L238-L241

Its implementation is not so good now (cf. #198), and its functionality should be in ColorTypes.jl rather than ImageCore.jl. Therefore, we may define Tuple(::Colorant) (cf. https://github.com/JuliaGraphics/ColorVectorSpace.jl/pull/131#discussion_r443177446) independently of the main topic of this issue. (I have not yet checked on the invalidation, though.)

[timholy]

The main reason not to treat channels as tuples is RGB vs BGR:

crgb = RGB(1, 0, 0)   # red
cbgr = BGR(1, 0, 0)   # red; constructor order is not the same as field order (storage order is a "detail")
trgb = tuple(crgb)    # presumably this gives (1N0f8, 0N0f8, 0N0f8)
tbgr = tuple(cbgr)    # what does this give?

Of course we could change the constructor order too, but it's a bigger conversation than RGB vs BGR: e.g., should ColorAlpha and AlphaColor take their arguments in opposite orders? How should RGB24 work on big- vs little-endian machines?

At the time the decision was made, Julia didn't have fast kwargs, and so the only way to support "generic" construction was positionally.

[timholy]

https://discourse.julialang.org/t/rgb-has-a-length-but-no-iterate/84446

[johnnychen94]

I'm open to any decision made here and will try to coordinate the downstream JuliaImages ecosystem.