if (( ${#} == 0 )) ; then while read -r __my_function ; do my_function "${__my_function}" done else target_utility "${@}" fi

Also unclear why the answer is criticized for providing a "more general case" since the OP said "You are right, this [base64] was just used as an example, though.

target_utility

The lonesome cat isn’t useless.  UUOCs are typically characterized by having exactly one filename argument; this one has none.  It connects the input to the function (which is the input of the if statement) to the output of the if statement (which is the input to the base64 –decode statement)

Well, here’s a non-recursive solution in which the main commands appear only once:

resolved through use of recursion

(It seems reasonable to assume users are often expected to occasionally adapt answers rather than expect to use them verbatim.)

This answer is one of various possible solutions for a "Bash function that accepts input from parameter or pipe" since the OP indicated [in a comment] that base64 was not the actual problem domain. As such, it makes no attempt to assure input is able to be directly read from a file.

but in a different situation target_utility "${@}" could represent more complex code

Though the OP's issue may not present a problem ideally resolved through use of recursion, other reader's problems may benefit from using it, or, from considering use of an wrapper function:

Duplicating non-trivial code in both the if and in the else could create unnecessary issues.

If one had to deal with the drain of such critique for every answer, perhaps site usage would go down. People have lives to lead and the OP is apparently already happy. IMO, it is time to move on.

n the end, this site is about helping community. All the associated answers and comments are available for a visitor to peruse and consider. It is decidedly less valuable to the community when all answers are identical.

he value of what really seems to be nitpicking seems questionable even if there is also value in a judicious hunt for theoretical ideals.

The title of the question is what triggered the process of finding this Q/A for material that aided development of the above to solve a real life problem described by the title. The OP declared that base64 decode was not the "real" problem; pedantic constraint of answers to a particular "example" seems less helpful. When this question and its answers were key to helping solve real problems, alternate answers can be gifts to the community in recognition of the fact that many more people will use this Q/A to solve problems. Since the answer is on-topic per the title, I feel it is "game on".

The answer credits others while solving a problem that wasn't optimally solved by other (helpful) answers at the time. I shared to help others. It is up to a reader to select answers and review for appropriateness to their needs. This almost looks like an attack when all that was required was an alternative answer standing on its own merits or demerits.

You should never rely on the presence or contents of anything under the .git directory. That's git's territory, not yours or the build system's. Use it's plumbing commands to get access to the information you need, rather than trying to read files directly. Git provides no guarantee about the location or contents of any of those files as far as I'm aware.

Note that UTF-8 characters can be used in branch names:

>, ==> and -> are valid branch names

This is not specific to Git-- it's part of how POSIX shells process commands. When you don't have quotes (or a preceding backslash), $ign is interpreted as an empty shell variable, so git only sees 'pew'.

Master (master/main) branch. The default production branch in a Git repository that needs to be permanently stable. Developers can merge changes into the master branch only after code review and testing. All collaborators on a project must keep the master branch stable and updated.

You can pre-seed your less pager with a search pattern so that you can move between files with n/N keys: [pager] diff = diff-so-fancy | less --tabs=4 -RFXS --pattern '^(Date|added|deleted|modified): '

xdg-mime default augmented-open.desktop x-scheme-handler/file-line-column This registers the augmented-open.desktop handler as the default handler for URLs using the file-line-column:// protocol.

for best results pipe rg --json output to delta: this avoids parsing ambiguities that are inevitable with the output of git grep and grep

Pull requests are quite welcome, and should target the next branch.

Nix

diff-so-fancy strives to make your diffs human readable instead of machine readable

The most popular is probably antigen but it's only in maintenance mode.

Every commit which is merged into main is considered a stable release. Every open PR is considered a beta release that I test locally.

Regression in 3.13: custom matcher hash argument improperly converted to keyword args, results in ArgumentError

Its a bit tricky because of the ambiguity of how the args get presented. You can see through the little demo the args are presented the same way whether its a straight kwargs or a hash, but the assignment of the args to parameters is different. def foo(*args) puts args.inspect end def bar(x=1, a:2) puts "x:#{x} a:#{a}" end foo(:a => 1) # [{:a=>1}] foo({:a => 1}) # [{:a=>1}] bar(:a => 1). # x:1 a:1 bar({:a => 1}). # x:{:a => 1} a:2

“…” would be cool, but (unless I’ve missed something in Ruby 3.2+), it can only delegate all args, and foo(1, …) is impossible.

The main change with Ruby 3.0 is that it differentiates between passing a hash and passing keyword arguments to a method with variable or optional keyword parameters. So def my_method(**kwargs); end my_method(k: 1) # fine my_method({k: 1}) # crashes

my_func(1, 2, 'foo' => 1, :kw => true) # ArgumentError: unknown keyword: "foo" even though Hash.ruby2_keywords_hash?(args.last) returns true.

even though Hash.ruby2_keywords_hash?(args.last) returns true. 🤯 And this statement (from #366): # If the last argument is Hash, Ruby will treat only symbol keys as keyword arguments # the rest will be grouped in another Hash and passed as positional argument. doesn't seem to be correct, at least in Ruby 3.0.

Yes, but to what version? A patch version only, e.g. you released 1.0.0, so the "next" version is 1.0.1? Why not 1.1.0? You don't know ahead of time what version you'll be releasing until it's actually released

The increment-after-release model makes sense for branching too. Suppose you have a mainline development branch, and you create maintenance branches for releases. The moment you create your release branch, your development branch is no longer linked to that release's version number. The development branch contains code that is part of the next release, so the version should reflect that.

Update email template to indicate that the link needs to be kept secure (e.g. do not share it)

Learning Blender 3rd Edition

Game Programming Algorithms and Techniques

Games, Design, and Play

Fundamentals of Game Design 3rd Edition

Introduction to Game Design, Prototyping, and Development 3rd Edition

This follows on a fairly widespread practice in various programming languages to use a leading underscore to indicate that a function or variable is in some way internal to a library and not intended for the end-user (or end-programmer).

accepting an answer doesn't mean it is the best one. For me it is interesting how argumentation of some users is reduced to "Hey, the editor has 5000+ edits. Do not ever think that a particular edit was wrong."

I'm not sure if I should write it in the answer directly, but I could also say that when an OP simply rolls back an edit without preemptively stating any reasoning in a comment etc., that tends to create the impression that OP is misguidedly claiming "ownership" of the content or feels entitled to reject changes without needing a reason.

Our goal is to have the best answers to every question, so if you see questions or answers that can be improved, you can edit them.

In fact, I think this self-answered Q&A of yours was already quite good by the standards of the site, and very useful - I've used it to close other duplicates several times. As someone who wears a "curator" hat around here, I want to make questions like this even better - as good as they can be - and make it clear to others that this is the right duplicate target to use when someone else asks the same question.

Then I gave the question a longer, more descriptive title: I made it an actual question (with a question mark and everything), and replaced the term "lazy evaluation" with a more concrete description. The goal is to make the question more recognizable and more searchable. Hopefully this way, people who need this information have a better chance of finding it with a search engine; people who click through to it from a search page (either on Stack Overflow or from external search) will take less time to verify that it's the question they're trying to answer; and other curators will be able to close duplicates more quickly and more accurately. This edit also improves visibility for some related questions (and I made similar changes elsewhere to promote this one appropriately).

We do want to avoid going around in circles on matters of style, and there has historically been a ton of discussion on Meta about what kinds of style edits are appropriate and what variation in style is acceptable. But in general, an author whose post is edited can expect to be out-voted - especially when the edit has a basis in policy. In short, these changes were not simply about "style", but about the site's goals for clarity, focus, precision and overall quality.

In principle, therefore, everyone has a say in the editing of posts, including the author. However, authors do not "own" the content here; it is licensed irrevocably to the site under a permissive Creative Commons license, which enables those edits.

As you've seen, there is no DM system, but you can invite users to chat directly. More generally, consider commenting on the question itself and @-ing the user who made the edit(s). To my understanding, this should work, and it may allow for a quick explanation that doesn't require going in to chat.

Try adding \ before your ls, e.g.: \ls | xargs file.

The input format of the xargs command doesn't match what any other command produces.

The input format of the xargs command doesn't match what any other command produces. Yes, it's bizarre. With -I, xargs ignores indentation, which is why the file names with initial spaces are mangled. Do not use xargs except with the -0 option or when you know your input doesn't contain characters that would confuse it.

The ls command doesn't expand wildcards, it's the shell that does. Do not parse the output of ls, it's practically never needed and often breaks something.

_

find . -maxdepth 1 -mindepth 1 | xargs -d'\n'

Do not pass arguments right into subshell, it's as unsafe as eval.

DO NOT PARSE LS.

Do not use xargs without -d when you do not want ' " \ to be handled specially.

This can lead to confusion if you expect to be able to access a Mash value through the property-like syntax for a key that conflicts with a method name. However, it protects users of your library from the unexpected behavior of those methods being overridden behind the scenes.

Comparing to Mash your custom class lacks mash-like deep initializer which is a different concern from MethodAccess. So you just need a smart initializer extracted from Mash (just like MergeInitializer but deep), probably implemented as a separate extension. So It's a initializer issue, not an issue of MethodAccess.

Wine isn't an emulator, it's a collection of code that interprets Windows executables for various different systems: "Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop." https://www.winehq.org/ FWIW, the Steam Deck relies heavily on a derivative of Wine for getting existing programs to run on the platform.Some programs will actually run faster under Linux + Wine than under Windows, which wouldn't be possible for an emulator running on the same hardware system.

Regardless of what your arguments are, the personal reasons of the developer are what matters for what platforms this game is provided on. You can choose to pay for the game, or not. Paying for the game supports the developer, and allows them to develop more. It is not reasonable to argue that someone should have put in additional unpaid effort to do something for unknown future benefit, or that they should charge less for a game because it's only available on one platform; that's their choice, and their decision.For context, development of Taiji was started in mid 2015; it took seven years to finish. That's with the Commercial Game Engine, and even with that, there were platform-based bugs that needed to be worked around (issues that won't be present on other platforms, or will have different presentations); here's just one of those, involving an issue around mouse sluggishness:https://taiji-game.com/2020/07/13/68-in-the-mountains-of-madness-win32-wrangling...If the developer is not already familiar with Linux, then there's a small mountain of language barriers around using Linux that needs to be overcome first, before being able to get to the game development phase. It's rare for game development to work on different platforms when it can't be tested on those different platforms. While it might be easy to cross-compile on a Windows system (e.g. via IL2CPP), that's only if everything works perfectly (which is unlikely to be the case). 

The high-level view of your responses are that they are an attack on the developer of this game, someone who has already put in seven years of effort to get to this point already (as demonstrated in the game development blog). The developer does not need that, and digging in deeper to become more aggressive will not help you get what you want. There are reasons for not developing on Linux, as there are for other platforms (e.g. MacOS, PS5, Switch). As great as it would be to just drop the same code on different platforms and have it work perfectly every time, that's not the reality. There are *always* platform-specific issues that crop up: "If you don't design your software with platform-nonspecificity in mind, then it just makes it harder. Nothing is truly impossible to port, disregarding hardware capabilities and computing speed. There's no such comprehensive "tool" for porting games to other platforms, though, since they all work differently under the hood." https://gamedev.stackexchange.com/questions/49375/what-are-the-main-requirements... Regardless of your own personal opinions on what should or shouldn't be done, the developer has already answered your question about Linux ports, in particular mentioning that it is appropriate for users to use Wine (in the form of Proton) to play Taiji on Linux. And, if the game not working on Linux is a showstopper for you, the developer recommends you consider purchasing on Steam due to a better refund poli

This library is no longer called vCardMate!

Why would a text message service require Location (GPS) permissions? Anyway I enabled this Location permission for testing. Heureka!!! Suddenly I was able to send text messages again to all the contacts which previously didn't work. The "Not sent, tap to try again" error was gone.

Glimmer DSL for Web intuitively supports both Unidirectional (One-Way) Data-Binding via the <= operator and Bidirectional (Two-Way) Data-Binding via the <=> operator,

Following a policy change by WhatsApp, many people are looking at alternative messaging options. The new WhatsApp policy requires people to share data with Facebook and associated companies.

WhatsApp is doing the exact thing it said it wouldn't do when it was acquired by Facebook seven years ago.

Driver management through Selenium Manager is opt-in for the Selenium bindings. Thus, users can continue managing their drivers manually (putting the driver in the PATH or using system properties) or rely on a third-party driver manager to do it automatically. Selenium Manager only operates as a fallback: if no driver is provided, Selenium Manager will come to the rescue.

How to use “case” to match class names? (=== not so funny)

def ===(other) @holder == other end

One way to potentially get around this is to have an object that simple holds a class and overrides the === operator to make case work properly:

The "From:" field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message.

In my experience, client software usually honors Reply-To, but I have only been exposed to a small fraction of the wide array of client software that people might use.

The autological word "eggcorn" is itself an eggcorn, derived from acorn.

our Rule 8 of Commas says, “Use commas to set off the name, nickname, term of endearment, or title of a person directly addressed.” Therefore, we would write: Good Morning, Mary. However, it is also acceptable to write Good morning, Mary. Good practice is to decide on a style and be consistent.

Formal application of punctuation with a salutation that doesn’t include an opening adjective (e.g., Dear Sir) would call for a comma preceding the person’s name as a proper form of address (e.g., Good afternoon, George). Whether to follow the name with a comma or a colon would be determined by the relationship’s context: Good afternoon, George, (comma for familiar) Good afternoon, George: (colon for formal) At the same time, you are correct in observing that current communication often omits the salutatory comma of address, particularly for shorter greetings (e.g., Hi Erik). This is becoming more common and acceptable, and it would be a matter of writer’s preference. You would be correct writing either Hi Erik or Hi, Erik. We would advise keeping the comma for longer or phrasal greetings such as Good afternoon, George.

The mortgage document which secures the promissory note by giving the lender an interest in the property and the right to take and sell the property—that is, foreclose—if the mortgage payments aren't made.

Some frameworks call this “template inheritance”. In this example, we might say that the application layout “inherits from” or “extends” the base layout. In Rails, this is known as nested layouts, and it is a bit awkward to use. The standard Rails practice for nested layouts is complicated and involves these considerations

But what if you want to reuse one layout within another?

Here’s my common practice: Every page in the app needs the standard HTML boilerplate with my common stylesheets and JavaScripts. I need a layout that provides these, but makes no assumptions on the actual body of the page. This is my “base” layout. Most – but not all – pages in the app need a common header and footer. This is my “application” (default) layout. I’d like the application layout to reuse the base layout to keep my code DRY.

ZenHub’s Issue dependencies not only help teams visualize relationships between pieces of work, but they save team members a lot of time that would otherwise be lost just hunting down information.

When relying on just a list of GitHub issues and comment references to other Issues, there’s a strong possibility that visibility into how these changes impact other tasks get lost or forgotten.

Tracking dependent relationships between Issues and whether something is blocking another piece of work is important with any project process because it creates a central hub where everyone can communicate what’s needed without relying solely on meetings or comments to uncover important connections.

his is a killer-feature which I miss since I switched from Jira to GitLab. I'm using GitLab on a daily basis even in solo-projects and I miss this every day. Everybody would find value to this when using Issues and realize, that some depend on others (so basically always).

This feature is a planned EE feature and so it is being tracked there. We currently have no plans for it to be in CE, so that is why this issue is closed.

Using an issue tracker without them is, in my opinion, a little like using an outlining program that only supports two levels of nesting, or like using Wiki software that doesn't have the concept of reverse links. Makes me sad!

It's also common to want to compute the transitive closure of these relations, for instance, in listing all the issues that are, transitively, duped to the current one to hunt for information about how to reproduce them.

Marking an issue as as a subtask of another. Having task lists in a description is a great start, but it doesn't help (AFAIK) navigating from child back up the chain to parent. Creating umbrella issues is a very common way to track the top-level focus areas for a release.

Thank you all for the detailed feedback. I want to emphasize we value your feedback. We believe it is a huge advantage for us to be able create GitLab transparently here in the community, with your contributions, whether they be ideas and analysis here or in actual code. Thank you for your excitement and passion.

@josephmarty mentioned desired outcomes as a focus. That is great. We encourage all types of feedback. Whether you want to highlight a problem, a desired outcome, have a design or implementation. Whatever you have, we welcome the ideas and encourage ongoing conversation.

(I grant that many of us contribute code to Gitlab, and would also like to participate as members of the development team in guiding the implementations, but clearly the core team has to have the final say in what direction that takes... unless someone wants to create and maintain their own fork of Gitlab ;) )

The parent/child relation is obviously a transitive, but "duplicate of" may be transitive too, but other relations like "related to" may not be transitive.

Another interesting property may be symmetry. For example "duplicate of" relation is symmetric, but "parent/child" is not.

The "meaning" will tell Gitlab how to interpret the relation. For example, a "parent/child" relation will have the meaning set to "one is a part of another", and then user may define a "subtask" and "subcomponent" relations to distinguish two situations, but Gitlab will understand because all three will have the same meaning and it can render a tree with three different kinds of edges.

There is also #8988 (closed) about custom fields. It there is some flexible architecture like in Drupal - all entities can have custom fields (and some form widget and some formatter), so building other features what needs to store data is more simple.

I thing you are doing a very subtle mistake which will become fatal in long-term. Your strategy to take small steps that cover as much functionality as possible is reasonable, but it is necessary to be careful, as it leads to a critical state when there is too much little stuff built up without proper structure to support it.

When the relations are implemented in the right way, they will simplify Gitlab, not make it more complex.

Another example are issue boards. They represent elegant use of a good infrastructure ­— it is all just a smart use of labels. It would be very complex feature without the use of labels.

Issue relations are meant to be the basic infrastructure to build on (at least that is how I meant it when I posted the original feature request). Just like the labels are just a binary relation between a issue and a "label", the relations should be just a ternary relation between two issues and a "label". Then you can build issue task lists on top of the relations like you've built issue boards on top of the labels.

That helps us keep GitLab simple as long as we can.

Introducing relationships between issues will considerably increase the complexity of GitLab. That is not a reason not to do it. But it is a reason for us to be strategic in when we do it, and ensure we have a good design that is scalable and aligns with our other initiatives.

This would be transformational in the scope of what issues can be effectively used for!

subtasks would give insight into how long it will take!

Blockers would give better insight into when an issue can be started,

Our flow is: The reporter reports an issue, and we developers create sub tasks upon that issue... in Redmine, we also had a percentage graph that would reach 100% when all sub-tasks were completed, was a great way about checking 1 item without the need to drill down all subtasks.

We use GitLab to manage software on interconnected embedded systems. What often comes up is this: New functionality on one system changes the protocol in a slightly incompatible way. Software on other systems have to be updated to understand the new protocol, take advantage of the new functionality, and stop complaining about the unexpected data. For this I would create multiple issues: Issues for the new functionality that we need. (Project A) Issue for defining the protocol changes. (Project A) Issue for implementing the protocol changes on the module. (Project A) Issues in related software projects for implementing the changes required to understand the new protocol. (Project B, C, D...)

bugzilla has had the concept of one or more ticket(s) blocking another for quite some time. We used that for over ten years before switching to GitLab and it is a feature I miss. A dependency tree between issues enables planning and workflow. This is can be seen as related to issues boards in that blocked issues should not be able to move ahead until the blockers are at least implemented perhaps reviewed.

It would be useful filter to have, also it would be useful to sort issues using topological order on Board and other issue listings, so the unblocked issues would be first.

Simple relations: [Issue A]---(relation R)--->[Issue B], which is a ternary (A, B, R) relation in a database.

We already have a very nice example of such tool and its great use: the Board, where labels are used to store metadata and the Board is built above this storage. Do the same with the relations -- simple metadata storage to build on.

Such a generic approach will allow the Relations to fit any reasonable workflow, because possible relations are defined by users, just like the Labels are.

duplicated by - Reciprocal of duplicates.

duplicates - Links issues so that closing one, will close the other (e.g. closing A will close B) For example, if issue B duplicates A: - closing B will leave A open - closing A will automatically close B duplicated by - Reciprocal of duplicates. For example, if issue A is duplicated by issue B: - closing B will leave A open - closing A will automatically close B

some of its properties needs to be specified, like whether the relation is transitive, so filtering can include or exclude issues related to related issues. For example when I want to see issues blocked by given issue, a filter needs to calculate transitive closure (recursively expand the relation on related issues until all reachable issues are found). On the other side, issue may be related to a second issue, but not to the third issue to which the second issue is related to.

Relation needs two labels, because of its direction ("blocks" vs. "blocked by").

I see specific relations in a similar way as labels. If a "label" is a binary relation between a label and an issue, "relation" between issues would be ternary relation between two issues and a label (from different set than ordinary labels).

Purpose of the relations should be to allow advanced analysis, visualization and planning by third-party tools or extensions/plugins, while keeping Gitlab's issues simple and easy to use.

One of the reasons that some projects don't use Gitlab's issues and use an external tracking platform is the lack of issues relations. Without relations issues are just flat, no way to actually track progress of big features. No way to create a "meta" issue that depends on 4 other or create subtasks and so on. The same problem exists on Github too. It would surely make a difference if Gitlab offers a full features tracking issue, instead of just flat issues. Relations is a major first step towards that.

Closing this issue down as a duplicate for now. If you feel that neither of these issues exactly fits your own proposal, pleae don't hesitate to reopen the issue. 😃

Sub tasks are just issues with a parent issue. When displaying them, always display the ancestor crumb trail.

Board view Subtasks are shown slightly indented from the main task Subtasks can be dragged out of the parent task to a new list to indicate their status. For subtasks with a different status to their parent, it displays a dummy parent (ghosted), above the subtask in the list, with the parent's status label visible against the dummy. Dragging the parent task to a different list changes the label of the child tasks as well, and any sub tasks already in its new list are re-organised under the parent and any dummy removed

From a branding perspective, it’s a bizarre and self-sabotaging move. Twitter is an established, internationally recognizable name. It’s cited in untold numbers of books, broadcasts, TV shows and news articles. Every internet-literate person knows what a tweet is. Needless to say, it will be hard to persuade regular people to refer to X as “X” instead of good ol’ Twitter. Plus, a single letter is difficult to google. These are just some of the many, many reasons why Twitter/X users are dunking on Musk’s new rebrand.

Work items can only have one kind of relationship to another (parent/child, blocking/blocked by/related).

Allow customers to set their own hierarchies

There are 2 main groups of locations for answering these questions. A single item A bunch of items (lists, boards, roadmaps, widgets)

(comment thread)

Hierarchy is about relationships between things. The most common hierarchical relationships are items that have a parent/child relationship.

Information and user interface components must be presentable to users in ways they can perceive.

By abstracting code away from "Files" and "Lines" we can offer more nuanced views like "Repeated Code Blocks" that could be refactored.

we should break down and MR into "Blocks"

Code block Metadata block Note block MR block (we should still be able to interact with the MR as a whole thing, e.g. leaving a generic comment on the whole thing)

A user wants to comment on a single parameter name in a function. It is highlighted as a unique part of the syntax tree, and they're not happy with the particular name the author of the MR chose. Problem: The user can only comment on the entire line, because "lines" are considered the most fundamental building block in our Diffs UI.

A user notices that an unchanged part of the diff already has features that are being implemented in the changes in the MR. The user leaves a comment on the unchanged part of the diff, telling the author that what they're trying to do is already present. Problem: The author cannot see that comment in the Changes tab, because the comment is outside the understood scope of the diff.

A reviewer wants to view all comments on an MR in a condensed list, and - for each one - see the context of that comment. Problem: Notes (on the MR) and Discussions (on the Diff) are treated differently, and Discussions necessarily come with Diff context. Diff context with Discussions is difficult to match with actual diffs because rendering diffs isn't designed for non-Changes-tab contexts

A reviewer would like to open a discussion on the MR description because they disagree with some of the conclusions, but want more clarification. Problem: The only way to have a conversation about the MR metadata (like title, description, labels, etc.) is to open a generic note on the whole MR. There's no way to scope a discussion to a part of the MR.

It’s a shift in mindset where the question changes from "were we busy doing the tasks?" to "did we move the needle for our organization to thrive?"

graphql

Please gentlemen, do not argue! I think we have to bear in mind that words sometimes can be deceitful and that is why we have to be very careful when using them in order to avoid misinterpretations. Thank you maljo for being such a gentleman! And you, eddiemel7778, is it alright if I ask you to choose a little better your words in order not to sound so "aggressive"?

Although, the discussion above has only been considering Figma, we need to keep in mind that there are other design tools out there.

I'm not sure that isolating design is something I'd prefer. I'd rather have an issue tagged (labeled) as such, and then attach design artifacts. I start a design in the same way I start frontend, with a list of requirements and acceptance criteria in mind, the design is just an artifact, a deliverable, an asset.

Interest

resolution of a design widget is more like closing an issue than an MR

Design widget is an extension of the issue description coz words can only describe so much.

I feel we need a agreeable definition of work-items. It is getting confusing already. If the goal is to avoid confusion then exceptions must be avoided.

One way is to have a very simple model of the same thing like Github and let users decide on the hierarchy of things. If Gitlab really want to go one step further and give users more then its really important simplicity is not killed in the process.

A task is used further down in the workflow. When I think about planning features, they occur before development takes off. The task is used by the developer as they are breaking down the issue into smaller components.

The comparison to MRs is a good one, because MRs have a distinct workflow and JTBD. As such, they are their own object record. I'm not sure whether a decision to move them to work items has been made, but I can see a case for and against.

I feel that the current design area should be a key part of the workflow on any work item, not just type of designs. As a PM I don't schedule designs independently. It's odd to open and close a design issue when it doesn't deliver value to the customer.

Discussions tied to the design itself is solved today with design manager, which allows those design discussions to occur within the context of a bigger issue. Bringing design manager into other work item types, like epics, would help, as would surfacing discussions from designs into the main discussion space. That behavior should be consistent for any work item type with design management enabled, rather than just for a design type.

This is true for other tasks besides design — frontend implementation, backend implementation, QA, etc — would we create unique types for each? Our suggestion here to teams today is often to break down the work into issues, or now tasks, for each uniquely assignable/trackable piece of work. You could do the same for design, where the task or issue is used to track status, discuss progress and maybe even WIP, but is focused on being SSOT for status rather than design.

Why should this conversation be separate from other conversations about the work to be done? Design is one consideration alongside frontend and backend considerations, which often all intersect and require the same participants. Shifting this discussion to a separate work item can result in disjointed conversations and difficulty finding where a decision was made.

Additionally, it reiterates the need to define "What isn't a Work Item?"

For example, I don't know how doing user research fits in, is it a task or this new "design" task.

Display product requirements, user flows, and design behaviors on each screen.

[With Zeplin] we started to engage both UX and engineering teams in the same conversations and suddenly that opened our eyes to what was going on, and overall streamlined our build process.

Track changes for each screen automatically – like Git for designs.

Document what to build and how designs should behave in a central, searchable, collaborative place for the entire product team.

Publish completed designs to Zeplin's platform while you iterate on designs in your design tool.

These can then be used to develop a definition that states the essence of the living thing—what makes it what it is and thus cannot be altered; the essence is, of course, immutable.

The Aristotelian method dominated classification until the 19th century. His scheme was, in effect, that the classification of a living thing by its nature—i.e., what it really is, as against superficial resemblances—requires the examination of many specimens, the discarding of variable characters (since they must be accidental, not essential), and the establishment of constant characters.

taxonomy, in a broad sense the science of classification