search

dat-ecosystem / organization

Organizational documentation for the dat-ecosystem
https://dat-ecosystem.org/organization/
7 stars 2 forks source link

implement and publish website #37

Open ninabreznik opened 1 year ago

ninabreznik commented 1 year ago

23

@todo

Hornet004 commented 1 year ago

worklog 2022.09.09 8:28PM worklog 2022.09.09 8:28PM worklog 2022.09.09 8:28PM

Hornet004 commented 1 year ago

worklog 2022.09.10 2:12AM

Hornet004 commented 1 year ago

worklog 2022.09.11 11:52AM worklog 2022.09.11 01:04PM

Hornet004 commented 1 year ago

worklog 2022.09.12 12:22PM

Hornet004 commented 1 year ago

worklog 2022.09.12 07:32PM

Hornet004 commented 1 year ago

worklog 2022.09.12 08:11PM

Hornet004 commented 1 year ago

worklog 2022.09.15 11:41PM

Hornet004 commented 1 year ago

worklog 2022.09.19 08:50PM worklog 2022.09.19 08:50PM worklog 2022.09.19 08:50PM worklog 2022.09.19 08:50PM

worklog 2022.09.19 08:50PM

Hornet004 commented 1 year ago

worklog 2022.09.22 09:43PM worklog 2022.09.22 09:43PM

Hornet004 commented 1 year ago

worklog 2022.09.24

Hornet004 commented 1 year ago

worklog 2022.09.26

Hornet004 commented 1 year ago

worklog 2022.10.01

Hornet004 commented 1 year ago

worklog 2022.10.03

Hornet004 commented 1 year ago

worklog 2022.10.09

Hornet004 commented 1 year ago

worklog 2022.10.12 02:07PM

Hornet004 commented 1 year ago

worklog 2022.10.14 10:23PM

Hornet004 commented 1 year ago

worklog 2022.10.15 7:40AM

Hornet004 commented 1 year ago

Tasks

serapath commented 1 year ago

feedback 2022.11.23

compoennt example

  1. The github issue link links to the one and only worklog comment where that specific version of the component design was created/produced as an @output.
  2. The dependencies link to the figma pages to the specific designs of the components that are used

so you understand correctly.

popovers component

You are correct, this is a mistake. The story was, that the popovers component was a component v0.0.1 That included all these individual designs in one component, but without names and versions.

Every design was a different mode of the popovers component, similar to how a button can be enabled and disabled and so on ...basically different states.

We then agreed to deprecate the popovers component and create individual components as successor components, each with their own name and version.

So yes - there should not be a name/version for those designs inside the content area of the popover component, instaed they should have been just names or labels for those individual states of the popover component, so please just ignore that name/version thing :-)

Sorry for the confusing, but good for pointing it out, so we can improve the video to present how we do figma versioning. thx

successors

So if you take an existing component version design on figma and create a final "deprecated" version, but the features or functionality solved by this now outdated components are solved instead by other components that were designed, then those components should be listed. They are essentially links to the figma page and position where those specific new "successor" components with the specified versions have been designed, so clicking the link jumps to that figma page for the specific successor component you clicked on.

A component can also have no succesor component and just be deprecated, because we decided to not use it anymore, e.g. imagine we would have created a <marquee> component but somehow decided to not use it anymore with no replacement ...even though, if it was used to display news, then maybe we should link to the component that we now use to display the same news? .... anyway, hope that makes it more clear.

merging components

ok, so i think there is a misunderstanding.

If you have two component A and B, you can make a component C that uses A and B as dependencies ...that is NOT a "merged component".

Instead - a "merged component" is the opposite of a "split component".

So you would deprecate 2 or more components at the same time and you link to the same new component you made which combines all the features of the two old previous components. You then link this new combined component as the only "successor component" in both old deprecated components.

We do NOT use these old components as dependencies in the new component. We do not use the old components anymore at all. But if somebody still has a link to those old designs, they can now find the link to the new successor component that replaced the old components.

So the technique is the same as in the split component, but instead of having one component and many new, we have many old deprecated and one new. Any case in between is also possible, but that is how it works.

Every time you deprecate components, you can list possible successor components that should be used from now on instead of the deprecated component.

Hornet004 commented 1 year ago

Tasks

ninabreznik commented 1 year ago

Feedback

Nov 26th 2022

Here is my feedback on the content of your work

Part 1: https://www.loom.com/share/dcf12139efe54730b1212ec76e7a8bf9 Part2: https://www.loom.com/share/f5a1ed25d5194192a9e566df7437d5d0

Links for inspiration (code is of course not the same as these components are part of certain frameworks):

And here are some of our existing components (which might need a little bit of brushing up before use)