27 Matching Annotations
  1. Last 7 days
    1. Do not include the same information in multiple places. Link to a SSOT instead.
    2. Having a knowledge base in any form that is separate from the documentation would be against the docs-first methodology because the content would overlap with the documentation.
    3. New information that would be useful toward the future usage or troubleshooting of GitLab should not be written directly in a forum or other messaging system, but added to a docs MR and then referenced, as described above.
    4. When you encounter new information not available in GitLab’s documentation (for example, when working on a support case or testing a feature), your first step should be to create a merge request (MR) to add this information to the docs. You can then share the MR in order to communicate this information.
    5. If the answer to a question exists in documentation, share the link to the docs instead of rephrasing the information.
    6. There is a temptation to summarize the information on another page. This will cause the information to live in two places. Instead, link to the SSOT and explain why it is important to consume the information
    7. At GitLab, we have so many product changes in our monthly releases that we can’t afford to continuously update multiple types of information. If we have multiple types, the information will become outdated.
  2. Jul 2020
    1. RDFa is intended to solve the problem of marking up machine-readable data in HTML documents. RDFa provides a set of HTML attributes to augment visual data with machine-readable hints. Using RDFa, authors may turn their existing human-visible text and links into machine-readable data without repeating content.
  3. Jun 2020
    1. Duplicated data is a common practice when working with non-relational databases as Firebase. It saves us from performing extra queries to get data making data retrieval faster and easier
  4. May 2020
    1. There are no plans to deprecate the REST API. To reduce the technical burden of supporting two APIs in parallel, they should share implementations as much as possible.
    1. Despite our best efforts to deal with all of those issues, over the course of time we fall behind. When you look at an issue it's sometimes unclear whether or not we intent to provide the functionality you propose, whether or not we fix the bug, whether or not the issue is a duplicate of another one. In order to restore a reasonable level of clarity we annually perform a House Keeping Iteration in which we go through all open issues. We categorize, label, fix, and close issues. This results in a wave of notification which is hard to deal with (our apologies) but in the end there is better understanding of what will happen to your ideas.
    1. This also ties in the "Single Source Of Truth", where even if I craft descriptive commit messages I will probably have to describe what I did in the MR comments anyways, so that feels like duplicate work.
  5. Apr 2020
    1. A miniature / iframe-friendly version of https://www.iubenda.com/en/user/tos/legal?ifr=false

      When you first sign up, it displays this in an iframe as https://www.iubenda.com/en/user/tos?ifr=true&height=680, with an "Accept and continue" button you must click to continue

    1. Running the same code in the browser and on the server in order to avoid code duplication is a very different problem. It is simply a matter of good development practices to avoid code duplication. This however is not limited to isomorphic applications. A utility library such as Lodash is “universal”, but has nothing to do with isomorphism. Sharing code between environments does not give you an isomorphic application. What we’re referring to with Universal JavaScript is simply the fact that it is JavaScript code which is environment agnostic. It can run anywhere. In fact most JavaScript code will run fine on any JavaScript platform.
    1. Also discussed in stackoverflow.com/questions/11003418/…

      Thank you for not just marking it as a duplicate simply because some similar but different question exists.

    1. let page = document.getElementById('buttonDiv');

      duplication: As a result of duplication, they somehow ended with this line being present here but not in the downloadable file which is supposed to have the same contents as the snippet shown here.

      They should have updated their static page generation script/process so that their main document referenced options.js and their generator literally included the contents of the referenced file inline. Then there is no chance of the contents of the inline snippet and downloaded snippet diverging and not matching.

      Evidently, however, the contents of each are managed independently (in other words, there is duplication), easily leading to the contents diverging, as they did.

  6. Mar 2020
    1. Technical cookies, preference, session and optimization cookies;Statistical cookies run by first-party solutions (eg. Matomo/Piwik or other solutions hosted/run by you);Statistical cookies by third parties (eg. Google Analytics), but only where the data is anonymized and is not used for profiling (even indirectly).
    1. Why is the changelog on a separate page and not here? The WordPress.org repository is just another place to download this plugin. I don’t want to maintain too many pages with the same content.
  7. Dec 2019
    1. It's confusing whether one should put things in gemspec development_dependencies or in Gemfile or in both.

      Duplication is bad since the lists could get out of sync. And the gemspec's development_dependencies should be a complete list. Therefore, my opinion is that that should be the canonical list and therefore the only list.

      Actually, what good is gemspec's development_dependencies? A contributor should clone the repo, run bundle, and get the dev dependencies that way. Therefore development_dependencies is unneeded and you should only list them in Gemfile.

      It is simpler to just use Gemfile, since it is a more familiar format. You can copy and paste content into it. For example, if you extract a gem out of an app, you may wan to copy/move some gems from app's Gemfile into new gem's Gemfile. It also generates a Gemfile.lock (which you shouldn't add to git).

    1. Having duplicate code is not ideal. One version of the code may be more up-to-date than another version, creating something similar to a race condition around code versioning. If a bug is found, it would need to be fixed in every place that shares the code while hoping that the developer can remember them all. An inconsistent bug fixing process could multiply bugs and create havoc in a codebase.
  8. Nov 2019
    1. Wow, looks like a lot of duplication in https://github.com/constelation/monorepo/blob/master/packages/Style_/src/index.native.tsx compared to https://github.com/constelation/monorepo/blob/master/packages/Style_/src/index.tsx to handle differences in props on the different platforms such as backfaceVisibility.

      And even structure/shape differences like:

      const style = { ...styleFromProps, ...this.props.style, ...Child.props.style }
      

      vs.

          propsToPass.style = [styleFromProps, this.props.style, Child.props.style]
      

      Is there no way to remove this duplication?