#metabrainz

iliekcomputers: Yeah! :)

yay!

One of GSoC 2018 ideas for MB is about editing interface for event setlist. Actually, it will probably impact its storage and its display too. Event setlists are stored as constrained text with a unique syntax that can easily be replaced with Markdown. (I wrote a 1:1 equivalence proposition already.)

This is why I looked into OTHER-77. Additionally, naiveaiguy, Daniel V. and Enjeck C. attached preliminary comparisons between some Markdown flavours during GCI contest.

Having a derivative of CommonMark similar to GitHub Flavoured Markdown (GFM) seems to be the way to go.

There are third-party extensions to Python implementation ( https://github.com/Python-Markdown/markdown/wik... ) of Markdown (for CB, Picard).

There are plenty of JS implementations (e.g. https://github.com/chjj/marked ) of Markdown/GFM (for BB, MB).

only thing i care about is that old edit notes are carried over logically

and that the new universal markup's markup is actually written anywher you'd use it

I would like Python foes to look into these extensions if possible.

Python foes? :D

Python coders sorry ^^

no I like foes better :D

currently we have edit #123456 autolink that isn't localized, if we go for an unified markup i hope this will be fixed somehow

yvanzo: Anything else?

For example, CB supports CommonMark’s links with angle brackets, not plain auto links (that is GFM extension).

zas: yes :)

Freso: no!

yvanzo: Alright!

helo again :)

So, those of you who are just catching up, I will quickly sum up the story so far :)

I hope it's not a piece of crap

For the redesign of MusicBrainz, we have decided to follow a component driven development. Just a fancy word for dividing the interface into parts, and build those parts. Those parts that can be reused, modified, tested individually.

We have been toying with the idea of whether we want to write our own React-components, or use react bootstrap. Yet to reach a conclusion on that one.

The other challenges that are there are, how do we maintain a sync between how it looks in mockups vs how it looks in code, describing properties/ behavior of a component, testing those components in an isolated environment, documentation.

React-storybook is something that is being used heavily for the above mentioned.

So, I tried setting up a mini version of it for us. Used react-bootstrap and css from our lobes theme. Thanks Leo_Verto for that one!

Here is the link:

It just has buttons, but imagine it being extended to all the other components as well.

This also solves the issue of waiting for our port to React to test out components. And easier for code noobs like me to test the components, make sure they are in sync with the design, etc etc!

brilliant!

and also other things like testing, documentations and how to use components :)

If you find it hard to imagine, here is one of the good ones out there.

selectedKind=Accordion&selectedStory=Default&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Factions%2Factions-panel

wait. this one. http://react.carbondesignsystem.com/?selectedKi...

You mean proper documentation as well?

That'd be neat

if you click on show info to the top right you can see how it generates docs :)

reosarevok: Yes, for the components. Like where to use it, what props to use, and so on.

it picks up props automatically, as for the rest you can type docs while writing code and it renders em up all nicely

there are other advantages to this too

chhavi_, samj1912: Final remarks about this? Otherwise I'll close up the meeting. :)

nothing now.

we can also do some neat testing - https://storybook.js.org/testing/react-ui-testing/

I'll digest this tomorrow

There is still work in it. Like modifying the css to match our mockups, new components that aren't there in react-bootstrap, etc. Will keep workin on it.

looks promising, chhavi_!

That will be all Freso

Alright then!

Thank you all for your time!

yvanzo: you're our Jira workflow fixer now, right? Can you make me a Blocked status for style tickets?

</BANG>

ruaok: sure :D also, a design walkthrough is due again, whenever you are free this week :)

Oh, sorry. Forgot to wait for the bang :D

yvanzo: As in "needs to wait for linked ticket to be resolved", for things like the attributes or like medium format attributes

we could also use https://github.com/airbnb/enzyme

chhavi_: how will project specific color schemes be handled by the design “system”? (Is “system” really useful/needed in the name of this project?)

zas: extract: https://gist.github.com/yvanzo/91d4f42f99d9ed26...

yvanzo: lol, the nomenclature is still a topic. I am sticking by whatever people decide to call it finally!

ohh, centralizting colour scheme variables in one place would be great for reusability

yvanzo: the same way lobes/bootstrap handles it

CatQuest: sure, there will be a migration path to be considered for edit notes, annotations, and so on.

a bunch of less variables

I have seen two ways of doing it so far. Either having a less variable file in the repo, or a colors story in the storybook

like this: https://lonelyplanet.github.io/backpack-ui/?sel...

currently I just helped chhavi_ plug-in lobes into react-bootstrap

chhavi_: IMHO, “system” can probably be dropped, just like there is no “software” at the end of “MusicBrainz Server”.

it worked as easily as I thought it would :P

\o/

!m samj1912

You're doing good work, samj1912!

reosarevok: that is actually the meaning of “Impl…” status.

yvanzo: not really IMO

That's "yes, this should be added, I've added an implementation ticket"

yvanzo: so we call it MBS-design?

well its MeBD no?

This is "this should not be even discussed until code has been written that makes it doable: then we can decide if this specific thing makes sense"

not just MBS?

(say: "someone wants an attribute, we can wait until it's possible to add, and then discuss it")

yvanzo: bitmap any reason why our react code doesn't hot reload?

chhavi_, samj1912: It is for *Brainz projects, not specifically for MetaBrainz website either.

thus metabrainz, no?

samj1912: that’s an issue of our Perl plugin for React.

is that fixable? :P

it becomes a PITA while dev.

Yes, it is our own code, that is fixable :)

yvanzo: basically "depends on" vs "resolved by"

(I can already add "depends on", but that doesn't get them out my "open tickets" queue! :D )

chhavi_, samj1912: Our Bootstrap theme is called Lobes. What about Hairstyle ;) or DesignBrainz?

DesignBrainz sounds nice :P

reosarevok: But it would continue to be an open ticket until the MBS issue is resolved regardless.

Unless you have a custom query that only looks for certain/specific statuses.

Acronym could be DeB as we owe it a better UX. :)

as for colour schemes. this could? make it possible for people to create their own themes (should they want white text on black& grey for example) ?

yvanzo: that sounds neat!

for things like annotations that can be edited it's not as big a deal as for edit notes. there had been some changes which made an old way of doing it oboslete and broken :D

Freso: if I only link it as depends on, yes, that's why I asked yvanzo for a separate status :)

+1 DesignBrainz

:D

reosarevok: And a separate status would (and should) still consider the ticket as open, is what I am saying.

[critiquebrainz] paramsingh closed pull request #159: CB-268: Update review only if contents are edited (master...cb-268/new-revision) https://git.io/v5D9F

reosarevok: Sorry, never mind me, Jira uses resolution and unresolved. I'm mixing up issue tracker lingos.

iliekcomputers: ping

I'd appreciate if someone could test pinging my name a littel

i can't ping my self

someone ping me by name once

nobody?

just once, please

CatQuest: ping :D

CatQuest: like this? :P

cheers

only once thnaks