fix typos in project files

Author: VisheshGrg

README.md

@@ -7,7 +7,7 @@ AboutCode is a family of FOSS projects to uncover data ... about software:
 -   where does the code come from? which software package?
 -   what is its license? copyright?
 -   is the code vulnerable, maintained, well coded?
--   what are its dependencies, are there vulneribilities/licensing issues?
+-   what are its dependencies, are there vulnerabilities/licensing issues?
 
 All these are questions that are important to answer: there are millions of free
 and open source software components available on the web for reuse.
@@ -61,13 +61,13 @@ Each AboutCode project has its own repository:
 -   **[Scancode.io](https://github.com/aboutcode-org/scancode.io)**: is a
     web-based and API to run and review scans in rich scripted pipelines, on
     different kinds of containers, docker images, package archives, manifests
-    etc, to get information on licenses, copyrights, source, vulneribilities.
+    etc, to get information on licenses, copyrights, source, vulnerabilities.
     The lead maintainer is @tdruez
 
 -   **[VulnerableCode](https://github.com/aboutcode-org/vulnerablecode)**: is a
     web-based API and database to collect and track all the known software
     package vulnerabilities, with affected and fixed packages, references and a
-    standalone tool Vulntotal to compare this vulneribility information across
+    standalone tool Vulntotal to compare this vulnerability information across
     similar tools. This is maintained by @tg1999 and @pombredanne
 
 -   **[univers](https://github.com/aboutcode-org/univers)** is a package to

docs/source/aboutcode-data/abcd.rst

@@ -193,7 +193,7 @@ Each of these objects has a few identifying attributes and eventually
 many tool- or application-specific data attributes. Each tool defines
 and documents the attributes they can handle and care for. When some
 agreement is reached on the definition of new attributes or objects, the
-ABCD dictionary may be updated accordingly with new objects types such
+ABCD dictionary may be updated accordingly with new object types such
 as for software security, quality or other interesting aspects.
 
 Objects are interrelated with other objects. Objects can relate to each
@@ -226,7 +226,7 @@ process the known objects and attributes.
 -  Attributes are name/value pairs.
 
 -  Attribute names are always strings, not numbers, not booleans, not any
-   other data format. In these strings, leading and trailing white spaces
+   other data format. In these strings, leading and trailing whitespace
    (spaces, tabs, line returns, etc) are not significant and can be safely
    ignored or removed.
 
@@ -254,7 +254,7 @@ Name conventions
    underscores. Names cannot start with a number. Names cannot contain
    spaces nor other punctuation, not even a dot or period.
 
--  Names are NOT case sensitive: upper or lowercase does not matter and
+-  Names are NOT case-sensitive: upper or lowercase does not matter and
    the standard is to use lowercase. It is a mistake to use upper or
    mixed case but this is something a parser receiving ABC Data should
    recover from nicely by converting the names to lowercase.
@@ -413,7 +413,7 @@ for the value type or meaning:
    is about some status.
 
 -  xxx_name: such as short_name. Indicates that the value is a name.
-   Commonly used for long_name, short_name. The bare name shout be
+   Commonly used for long_name, short_name. The bare name should be
    preferred for the obvious and most common way an object is named.
 
 -  xxx_flag, is_xxx, has_xxx: such as is_license_notice. Indicates
@@ -462,7 +462,7 @@ The minimal way to identify top level objects is the combination of a
 implicit when two parties are exchanging data privately or explicit
 using the "source" attribute.
 
-Within a source, we use the most obvious and natural identifies for an
+Within a source, we use the most obvious and natural identifiers for an
 object. For example:
 
 -  For Products, Components and Packages we can use their name and
@@ -834,7 +834,7 @@ writing primarily by humans.
    separators).
 
 -  Beware of parser shenanigans:  Most YAML parsers recognize and convert
-   automatically certain data types such as numbers, booleans or dates.
+   automatically certain data types such as numbers, booleans, or dates.
    You should be aware of this because the ABC Data strings may contain
    date stamps. You may want to configure a YAML parser to deactivate some
    of these automated format conversions to avoid unwanted conversions.
@@ -920,7 +920,7 @@ mappings to ABC Data attribute and object names.
 Since ABC Data can be related by reference, the preferred (and
 cumbersome) way to store ABC Data in a spreadsheet is to use one tab for
 each object type and use identifying attributes to relate objects
-between each others across tabs. For instance, in a Bill of Materials
+between each other across tabs. For instance, in a Bill of Materials
 (BOM) spreadsheet for a Product, you could use a tab to describe the
 Product attributes and another tab to describe the Components used in
 this Product and possibly additional tabs to describe the related
@@ -930,7 +930,7 @@ packages and files corresponding to these
    versions, unicode and UTF-8 to avoid damaging content (aka. mojibake)
 
 Spreadsheet tools such as Excel or LibreOffice  automatically recognize
-and convert data to their own format: a date of 20016-08-17 may be
+and convert data to their own format: a date of 2016-08-17 may be
 converted to a date number when a CSV is loaded and difficult to recover
 as a correct original date stamp string afterwards. Or a version 1.0 may
 be irreversibly converted to 1 or 1.90 to 1.9 losing important version

docs/source/archive/contributor_project_ideas.rst

@@ -13,10 +13,10 @@ AboutCode is a project to uncover data ... about software code:
 
 
 * where does the code come from? which software package?
-* what's is its license? copyright?
+* what is its license? copyright?
 * is the code secure, maintained, well coded?
 
-All these are questions that are important to find answers to: there are million
+All these are questions that are important to find answers to: there are millions
 of free and open source software components available on the web.
 
 Knowing where a software package comes from, if it is vulnerable and what's its
@@ -28,7 +28,7 @@ more free and open source software.
 Our tools are used to help detect and report the origin and license of source
 code, packages and binaries as well as discover software and package
 dependencies, and track security vulnerabilities, bugs and other important
-software package attributes. This is a suite of command line tools, web-based
+software package attributes. This is a suite of command-line tools, web-based
 and API servers and desktop applications.
 
 Table of Contents
@@ -250,13 +250,13 @@ The features and TODO for this updated server would be:
 * Aggregate more and new packages vulnerabilities feeds,
 
 * Automating correlation: add smart relationship detection to infer new
-  relatiosnhips between available packages and vulnerabilities from mining the
+  relationships between available packages and vulnerabilities from mining the
   graph of existing relations.
 
 * Create a ScanCode plugin to report vulnerabilities with detected packages
   using this data.
 
-* Integrate API lookup on the server withe the AboutCode Manager UI
+* Integrate API lookup on the server with the AboutCode Manager UI
 
 * Create a UI and model for community curation of vulnerability to package
   mappings, correlations and enhancements.
@@ -474,7 +474,7 @@ Copyright detection is the slowest scanner in ScanCode. It is based on NLTK part
 of speech tagging and a copyright grammar.
 
 The goal of this project is to refactor Copyright detection for speed and
-simplicity possibly implementaing a new parser (PEG?, etc) or reimplementing
+simplicity possibly implementing a new parser (PEG?, etc) or reimplementing
 core elements in Rust with a Python binding.
 
 This would include also keeping track of line numbers and offsets where copyrights are found.
@@ -549,7 +549,7 @@ to effectively support proper inventory of installed packages without running
 the containers.
 
 This includes determining which packages are installed in Docker layers for
-RPMs, Debian or Alpine Linux. And this woudl eventually require the integration
+RPMs, Debian or Alpine Linux. And this would eventually require the integration
 of ScanCode.
 
 
@@ -580,7 +580,7 @@ TraceCode does system call tracing only today.
 - This project also would cover updating TraceCode to use the Click comamnd line toolkit
   (like for ScanCode).
 
-- Finally thsi project should improve the tracing of the lifecycle of file
+- Finally this project should improve the tracing of the lifecycle of file
   descriptors in TraceCode build. We need to improve how TraceCode does system
   call tracing by improving the way we track open/close file descriptors in the
   trace to reconstruct the lifecycle of a traced file.
@@ -642,7 +642,7 @@ This requires a good understanding of packaging and Python.
 **Package URL implementations in many programming languages**
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-We have a purl implmentation in Python, Go and possibly Java today.
+We have a purl implementation in Python, Go and possibly Java today.
 
 The goal of this project is to create multiple parsers and builders in several
 programming languages:

docs/source/archive/gsoc/org_pages/gsoc_2017.rst

@@ -71,7 +71,7 @@ relevant:
 * Detailed description of your idea including explanation on why is it innovative and what it will
   contribute
 
-  * hint: explain your data structures and the main processing flows in details.
+  * hint: explain your data structures and the main processing flows in detail.
 
 * Description of previous work, existing solutions (links to prototypes, bibliography are more
   than welcome)

docs/source/archive/gsoc/org_pages/gsoc_2019.rst

@@ -4,7 +4,7 @@ Google Summer of Code 2019
 ==========================
 
 AboutCode is participating in the Google Summer of Code in 2019 as a mentoring org. This page
-contain all the information for students and anyone else interested in helping.
+contains all the information for students and anyone else interested in helping.
 
 AboutCode is a family of FOSS projects to uncover data ... about software code:
 
@@ -13,7 +13,7 @@ AboutCode is a family of FOSS projects to uncover data ... about software code:
 - what is its license? copyright?
 - is the code secure, maintained, well coded?
 
-All these are questions that are important to answer: there are million
+All these are questions that are important to answer: there are millions
 of free and open source software components available on the web for reuse.
 
 Knowing where a software package comes from, what is its license and if it is
@@ -420,11 +420,11 @@ DeltaCode projects
 DeltaCode is a tool to compare and report scan differences.
 When comparing files, it only uses exact comparison.
 The goal of this project is to improve the usefulness of the delta by also
-finding files that are mostly the same (e.g. quasi or nrea duplicates) vs. files
+finding files that are mostly the same (e.g. quasi or near duplicates) vs. files
 that are completely different. Then the DeltaCode comparison core should be
 updated accordingly to detect and report material changes to scans (such as
-new, update or removed licenses, origins and packages) when changes are also
-meterial in the code files (e.g. such that small changes may be ignored)
+new, updated or removed licenses, origins and packages) when changes are also
+material in the code files (e.g. such that small changes may be ignored)
 
 
 - **Level**
@@ -454,7 +454,7 @@ TraceCode projects
 
 TraceCode does system call tracing only today. The primary goal of this project
 is to create a tool that provides the same results as the strace-based tracing
-but would be using using ELF symbols, DWARF debug symbols, signatures or string
+but would be using ELF symbols, DWARF debug symbols, signatures or string
 matching to  determine when and how a source code file is built in a binary
 using only a static analysis. The primary target should be Linux executables,
 though the code should be designed to be extensible to Windows PE and macOS Dylib and exes.
@@ -593,13 +593,13 @@ The features and TODO for this updated server would be:
 - Aggregate more and new packages vulnerabilities feeds,
 
 - Automating correlation: add smart relationship detection to infer new
-  relatiosnhips between available packages and vulnerabilities from mining the
+  relationships between available packages and vulnerabilities from mining the
   graph of existing relations.
 
 - Create a ScanCode plugin to report vulnerabilities with detected packages
   using this data.
 
-- Integrate API lookup on the server withe the AboutCode Manager UI
+- Integrate API lookup on the server with the AboutCode Manager UI
 
 - Create a UI and model for community curation of vulnerability to package
   mappings, correlations and enhancements.
@@ -657,7 +657,7 @@ There are several areas to research and prototype such as:
 - A data structure to match efficiently a batch of fix-width checksums (e.g.
   SHA1) against a large index of such checksums, where each checksum points to
   one or more files or packages. A possible direction is to use finite state
-  transducers, specialized B-tree indexes, blomm-like filters. Since when a
+  transducers, specialized B-tree indexes, bloom-like filters. Since when a
   codebase is being matched there can be millions of lookups to do, the batch
   matching is preferred.
 
@@ -677,7 +677,7 @@ There are several areas to research and prototype such as:
 
 - Feature hashing research: we deal with many "features" and hashing to limit
   the number and size of the each features seems to be a valuable thing. The goal
-  is to research the validaty of feature hashing with short hashes (15, 16 and
+  is to research the validity of feature hashing with short hashes (15, 16 and
   32 bits) and evaluate if this leads to acceptable false-positive and loss of
   accuracy in the context of the data structures mentioned above.
 
@@ -708,5 +708,5 @@ This is a green field project.
 Mentoring
 ---------
 
-We welcome new mentors to help with the program and require some good unerstanding of the project
+We welcome new mentors to help with the program and require some good understanding of the project
 codebase and domain to join as a mentor. Contact the team on Gitter.

docs/source/contributing.rst

@@ -3,7 +3,7 @@ Contributing to AboutCode
 #########################
 
 We welcome you and your interest in contributing to open source software! AboutCode
-is always looking for enthusiatic contributors and we are happy to help with any questions
+is always looking for enthusiastic contributors and we are happy to help with any questions
 or comments. Here a few resources to get started:
 
 1) Take a look through our public repos here: https://github.com/aboutcode-org/

docs/source/contributing/contrib_doc.rst

@@ -81,7 +81,7 @@ Ensure that you have the latest files::
     git pull
     git status
 
-Before commiting changes run Continious Integration Scripts locally to run tests. Refer
+Before committing changes run Continuous Integration Scripts locally to run tests. Refer
 :ref:`doc_ci` for instructions on the same.
 
 Follow standard git procedures to upload your new and modified files. The following commands are
@@ -189,7 +189,7 @@ Intersphinx
 ScanCode toolkit documentation uses `Intersphinx <http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html>`_
 to link to other Sphinx Documentations, to maintain links to other Aboutcode Projects.
 
-To link sections in the same documentation, standart reST labels are used. Refer
+To link sections in the same documentation, standard reST labels are used. Refer
 `Cross-Referencing <http://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#ref-role>`_ for more information.
 
 For example::
@@ -203,7 +203,7 @@ For example::
 
     It refers to the section itself, see :ref:`my-reference-label`.
 
-Now, using Intersphinx, you can create these labels in one Sphinx Documentation and then referance
+Now, using Intersphinx, you can create these labels in one Sphinx Documentation and then reference
 these labels from another Sphinx Documentation, hosted in different locations.
 
 You just have to add the following in the ``conf.py`` file for your Sphinx Documentation, where you
@@ -242,7 +242,7 @@ For more information, refer this tutorial named
 
 .. _doc_style_conv:
 
-Style Conventions for the Documentaion
+Style Conventions for the Documentation
 --------------------------------------
 
 1. Headings

docs/source/contributing/writing_good_commit_messages.rst

@@ -16,7 +16,7 @@ The main style points are these:
 
 Subject:
 
-- Add a issue number at the end of the line when available as in "#234"
+- Add an issue number at the end of the line when available as in "#234"
 - Limit the subject line to 50 characters
 - Capitalize the subject line
 - Do not end the subject line with a period
@@ -35,7 +35,7 @@ Body:
 Other comments:
 
 We like to suffix the subject line with an issue number. If this was a trivial change it may not
-have one though. If it had one a you would use ``#156`` as a suffix to the first line.
+have one though. If it had one you would use ``#156`` as a suffix to the first line.
 
 We like to tell why the commit is there and use an imperative style, like if you were giving an
 order to the codebase with your commit: