See https://lwn.net/Articles/937528/

We likely need to establish some minimal privacy policy since we have projects that collect and accumulate data, some of which contains things to identify a user (as publicly made available by these users, such as an AUTHOR files and so on).

@armijnhemel @johnmhoran @DennisClark @mjherzog

Today we have header-level data in ScanCode data that is a tad ad-hoc. For instance:

{
  "scancode_notice": "Generated with ScanCode...",
  "scancode_version": "2.1.0.post55.ff2948e",
  "scancode_options": {
    "--info": true,
    "--format": "json-pp"
  },
  "files_count": 1,

  ..files, etc ... regular ABC Data.....
}

We should normalize this and support having multiple tools providing some log that they touched the data.
Here is what I suggest: store these in a top level "header" attribute. This attribute would contain a list. Each list item would be an object.
With this in mind the new ScanCode output would look like this:

{ 
  "header" : [
    { 
      "tool": "scancode-toolkit",
      "tool_version": "2.1.0.post55.ff2948e",
      "date": "2017-09-12T12:23:12",

      "scancode_notice": "Generated with ScanCode...",
      "scancode_options": {
        "--info": true,
        "--format": "json-pp"
       },
      "files_count": 1,
      [.... any other attributes that a tool may want to add, such as a scanned path, etc] ,
    }
  ]
  ..files, etc ... regular ABC Data.....
}

And with several tools having "touched" the data:

{ 
  "header" : [
    { 
      "tool": "scancode-toolkit",
      "tool_version": "2.1.0.post55.ff2948e",
      "date": "2017-09-12T12:23:12",

      "scancode_notice": "Generated with ScanCode...",
      "scancode_options": {
        "--info": true,
        "--format": "json-pp"
      },
      "files_count": 1,
      [.... any other attributes that a tool may want to add, such as a scanned path, etc] ,
    },
    { 
      "tool": "aboutcode-mamanger",
      "tool_version": "3.1.0",
      "date": "2017-09-13T15:23:12",
      [.... any other attributes that a tool may want to add, such as a scanned path, etc] ,
    },
    { 
      "tool": "vulnerablecode",
      "tool_version": "0.1.0",
      "date": "2017-09-13T16:23:12",
      [.... any other attributes that a tool may want to add, such as a scanned path, etc] ,
    }
  ]
  ..files, component, packages etc ... e.g. regular ABC Data.....
}

In this context these would be the only fields that are expected in a header item:

      "tool": "aboutcode-mamanger",
      "tool_version": "3.1.0",
      "date": "2017-09-13T15:23:12",

and the convention would be that each tool exporting ABCD data would:

1. preserve the previous header
2. add one "log" entry to the header

The benefits of all this are:

1. clear header data, no longer mixed with other regular code-related data
2. minimal trail/log of which tool touched and eventually transformed the data which is useful for tracing and documentation

The AboutCode pages on ReadTheDocs are outdated and due for a refresh. The major changes to make are:

• Update the main page based on changes outlined in:
  AboutCode-RTD-changes-22.03.04.docx
• Archive the GSoC and GSoD pages and remove them from the TOC and index because we have decided to use the GitHub wikis for our participation in those programs. We may want to move some of this content to the GH wikis - TBD.

We need to automate posting project releases to the News feed on aboutcode.org. Aboutcode.org is the primary website for information about any and all of our many projects so it would be a good place to post project releases so that a viewer can see consolidated information across projects.
The idea is to create a News template that would be a requirement for any release. The information should be very simple with a simple title like "Project version x.y.z released" with links to the Releases page for each project.
We already seem to have a basic template as with https://www.aboutcode.org/news/2021-12-17-scancode.io.html, but the posting process is manual.

Description

Today we use #12 as a reference to an issue.
When the code is move to another repo, 12 will point to another issue.
We should consider switching to something using full URLs in code comments
and this Reference: https://github.com/nexB/dejacode/issues/1198 just above the signoff in commits

Description

Tiny correction in the readme file

Select Category

• Inconsistency []
• New Section Request []
• General Improvement []
• Typo/Mistakes [✅]
• Other []

Description

The version in https://www.aboutcode.org/projects/aboutcode-toolkit.html is outdated.

See nexB/aboutcode-toolkit#460

I am interested in improving About Code web presence by adding schema and improving SEO.

Scan for all clues:

To scan for licenses, copyrights, urls, emails, package information, and file information

./scancode -clip -e -u --format html-app samples samples.html
Scan for license and copyright clues:

./scancode -cl --format html-app samples samples.html

Scan for emails and URLs:
./scancode -e -u --format html-app samples samples.html

Scan for package information:

./scancode -p --format html-app samples samples.html

Scan for file information:

./scancode -i --format html-app samples samples.html

To see more example scans:

./scancode --examples

All these commands are showing an error.

(base) rituraj@rituraj-G7-7588:~/Documents/git/scancode-toolkit$ ./scancode -clip -e -u --format html-app samples samples.html
Error: no such option: --format

I think --format is an additional option to the command.

Description

In the README.md file --> Projects Section, the username of the lead maintainers is not pointing to their own profile link.

Description

Link present in aboutcode wiki https://aboutcode.readthedocs.io/en/latest/aboutcode-docs/writing_good_commit_messages.html is now working. It shows This page does not exist yet error.

Link to Documentation Page

https://github.com/nexB/aboutcode/wiki/Writing-good-commit-messages

Select Category

• Inconsistency
• New Section Request
• General Improvement
• Typo/Mistakes
• Other

Description

In the documentation page of GSoC and GSoD, there is no description of these programs.
A basic description of these would help contributors to know about those.

Link to Documentation Page

1. https://aboutcode.readthedocs.io/en/latest/gsoc-toc.html_
2. https://aboutcode.readthedocs.io/en/latest/gsod-toc.html_

Select Category

• Inconsistency
• New Section Request
• General Improvement
• Typo/Mistakes
• Other

Modify the aboutcode wiki pages to point to corresponding pages in aboutcode.readthedocs.io, while deleting content already present in the RTD pages.

Pages to be modified:

• Home
• Contributor Project Ideas
• Google Season of Documents (GSOD) 2019
• GSOC 2017
• GSOC 2018
• GSOC 2019
• Writing good commit messages

The GSOC 2020 wiki page is left as it is, as this will be linked from the GSoC official website.

We need to determine whether / how to use AboutCode as a top-level site/directory for all of our project documentation. The Subprojects feature - https://docs.readthedocs.io/en/stable/subprojects.html - may support this, but it is not clear how it works and how much it would impact the structure and operation of the RTD pages for subprojects like SCTK, SCIO, etc.
I think that we are looking for something that would allow us to easily maintain a directory of links to the various projects with minimal impact on how we manage the doc for each subproject.
I propose that aboutcode-toolkit would be a a good project to test with.

Short Description

Space between title and subtopics( UI, UX) can be changed to increase the readability of end user. For example, in community section, the space between community(heading) and following sub topics can be increased.

How This Feature will help you/others

increases the readability of end user by differentiating headings from subheadings.

Can you help with this Feature

sure

We need to have a somewhat detailed entry/doc page on license scoring:

• How its calculated
• What different scores mean
• How to interpret, etc

Description

We have things that are org-wide such as coding standards and more. We should have a simple way to document and adopt these.
I suggest a process similar to Python PEPs, where we have a simple text document that goes through a PR and lands in this repo.
These could be numbered ABC-XXXX

This page will support the GSoD 2020 application.

After reading aboutcode-data it's still unclear to me how this standard relates to dot-about which ScanCode is currently using.

@pombredanne, could you please elaborate on that?

When describing software packages, like Java libraries, it's quite essential to also capture any dependencies / relationships between packages. The current ABCD spec seems to be quite loosely defined in this regard. A bit too loose for my taste probably. Could you give a concrete example how e.g. the dependency of mockito-core on junit would be represented in ABCD in YAML format?

We need a better way to review project documentation to suggest improvements and corrections to our project/product documentation. It is slow and difficult to review doc changes in a PR format.

This page - https://docs.readthedocs.io/en/stable/downloadable-documentation.html - seems to indicate that we could generate a PDF (or ePub or HTML) format document by adding it to a Sphinx-based workflow.

PDF output would be very useful for offline use and it could be a good way to print a review copy that anyone could annotate with a PDF editing tool.

The following tasks are remaining in terms of improving the Scancode-Toolkit Docs
[Before Next Release and Migration]

This part I'll complete.

1. Major Improvements

• Getting Started Section [ 214b8e8 ]
• Support for First-Timers [ cdc4976 ]
• Document support For pip install [ 94b50ca ]
• Document python 3 related installations and others [ 94b50ca ]

2. Linking Sphinx Docs

• Add Intersphinx to nexB/aboutcode [ 6dbe59f ]
• Add Intersphinx to nexB/scancode-toolkit [ 3187b34 ]
• Add Intersphinx related Docs [ f1b2414 ]

The following sections I'd need help on:-

1. CLI Options Marked as [ToDo] (For Improvement)

• --license-score [Basic Options] #28
• --generated [Basic Options]
• --reindex-licenses [Core Options]
• --license-clarity-score [Post Scan Options]

2. Related Bugs Open

• --custom-template nexB/scancode-toolkit#1760
• pip install scancode-toolkit nexB/scancode-toolkit#1778
• --filter-clues nexB/scancode-toolkit#1758
• --summary-by-facet nexB/scancode-toolkit#1759

Description

In Project section in Readme.md the projects description show inconsistent format as somewhere the colon is missing and one project idea is not start with Capital letter.

Link to Documentation Page

Where the confusion/inconsistency/incomplete documentation is.

• In Readme.md Project section

Select Category

• Inconsistency []
• General Improvement []

can someone suggest how to remove this error and what does is the error saying

We currently have the GSoC projects hidden under: https://aboutcode.readthedocs.io/en/latest/archive.html#table-of-contents.
Please move GSoC to the TOC top level after Contributing to AboutCode. It is not intuitive to look for these under Archived Pages.

At some point we will want to also promote GSoD, but we can leave it and Contributor Project Ideas (old) under the Archived Pages for now. We should remove the TOC level under Archived Pages if that is easy to do.
It would be nice to make the change quickly so that we can post the better link with the News item for completing GSoC 2022 on aboutcode.org.

On this page: https://github.com/nexB/aboutcode/blob/master/docs/source/help.rst the various links seem to be in markdown format. We will need to change these to the equivalent RST link syntax to use with the Sphinx documentation system.

Working on the PURLdb RTD, I noticed a variety of ways we refer to the names of services, functions and other concepts in our documentation. See my purldb comment for examples. It would be useful to create and maintain a glossary of relevant terms and names we can use as a reference.

Per @mjherzog
Roadmap might be one item that should be a file on primary repo like README

Assigned to @DennisClark to investigate

Maybe it makes sense to consider using the existing CodeMeta standard instead of coming up with aboutcode-data. If CodeMeta turns out to not suit our needs, maybe we still could borrow some ideas.

@pombredanne, what do you think?

Description

The current page: https://www.aboutcode.org/projects/aboutcode-toolkit.html has the SPECIFICATION points to https://github.com/nexB/aboutcode-toolkit/blob/develop/SPECIFICATION.rst , but we now have the RTD link which I believe we should use https://aboutcode-toolkit.readthedocs.io/en/latest/specificaltion.html instead.

Select Category

• Inconsistency []
• New Section Request []
• General Improvement [x]
• Typo/Mistakes []
• Other []

Short Description

Migrate FOSS projects under nexB organization on GitHub to aboutcode-org on GitHub.

How This Feature will help you/others

Transferring ownership of AboutCode projects on GitHub from nexB to aboutcode-org will demonstrate to the community our FOSS for FOSS commitment with the projects in a FOSS organization on GitHub instead of commercial entity.

This will facilitate displaying individual projects on the new aboutcode.org site. We will also revisit the plan to better index the docs for AboutCode projects: #129

Possible Solution/Implementation Details

GitHub published docs on how to transfer ownership between organizations: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

GitHub should create automatic redirects following their docs:
All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL.

There could be some issues with integrations and their tokens, including:

• PyPI deployment
• Azure DevOps
• GitHub Actions
• Read the Docs
• Slack
• Others?

There could be some issues with migrating permissions and collaborators in the new organization.

Example/Links if Any

More documentation on transferring a repo owned by your org: https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#transferring-a-repository-owned-by-your-organization

Can you help with this Feature

I can help with some testing but this would require someone with advanced git (and git troubleshooting) skills.

Actual repos to migrate

This list is sorted so we start with a few smaller, less critical repos to validate the move process:

• aboutcode-org/matchcode-toolkit#10
• nexB/aboutcode-toolkit#559

@pabs3 reported to me that we still have some outdated freenode references https://github.com/search?q=org%3AnexB+freenode&type=code

We should use only Gitter and liberachat

I think that all Documentation of aboutcode is very messed up and we should not just copy blindly from wiki and update here. Many of the docs are using an old version of the scancode-toolkit command, So we should take care of that and correct it then only we should push it. By just copying and pasting they look like very messed (the font is also not right, spacing is also not proper)and it will be a problem later because for modification we have to take a look on every page. So I think whenever we are updating doc of aboutcode we should modify it at that instant and then only we should push it.

The second thing is wiki doc is not well defined and are the quick tutorial. During forwarding it from wiki to aboutcode doc, we should take care of this also else this will cause a problem. Later, when we have to do modifications, then all previous work will be useless and we have to remove the code.

Description

A brief description of the Documentation Improvement or New Section request.
add the testing page for aboutcode. cc4b496

Link to Documentation Page

Where the confusion/inconsistency/incomplete documentation is.

Select Category

• Inconsistency []
• New Section Request []
• General Improvement []
• Typo/Mistakes []
• Other []