This is now done, aside from a minor issue noted below:

softwareheritage-indexer=# select count(*) from revision_intrinsic_metadata where metadata = '{"@context": "https://doi.org/10.5063/schema/codemeta-2.0"}'::jsonb;
 count 
-------
     0
(1 row)

I don't think it's a good idea to move specs from the specific components they specify to a different repository (swh-docs), because that will just increase the chances (which are already quite high) that they will get out of sync.

In D1430#31493, @anlambert wrote:

I knew about the manual landing from us but I am not a big fan of all this noise added to the commit message by arc.
Based on my understanding, if the original commit author is able to push after we accept a diff, this noise will not
be present. Anyway, that's not a blocker to integrate changes so I will also proceed like this in the future.

In D1430#31490, @anlambert wrote:

Third: everyone else: once a change is accepted, you can land it yourself by doing first arc diff D1430 and then arc land

I think you mean arc patch D1430 then arc land

@mcv21: first, apologies for the conflicting communication. We don't have a lot of external contributors (yet), so our processes are not very oiled on that front (yet).

In T1683#31093, @moranegg wrote:

The problem with having it in the docs, is that specs of higher level (like metadata workflow) must be in a specific repository, or can I have a specs folder in swh-environment?

In T1685#31076, @anlambert wrote:

@zack, I tried to handle that task but I do not have access to domains configuration from the Gandi interface.

In D1430#31457, @mcv21 wrote:

[I think I can't merge this myself]

In T1683#31054, @moranegg wrote:

I need this decision for different specs, for example:

• Legacy software deposit
• Sparse / Metadata deposit (now in docs)
• Metadata workflow- How do we dill with software metadata (T1344)

I think we need to have a conversation about how we decide to add support for rendering specific file formats in the webapp.
There are a million different file formats out there, why are we rendering Markdown and Jupyter notebooks and not something else?
When we have support for a million (or even just a dozen, really), are we going to test for which-is-which in a long chained series of IFs in a template? That doesn't seem really wise…
How do we decide if something is a given file format or not, especially considering that getting it wrong might even entail security vulnerabilities, injections, etc.? (because we're rendering content we do not control directly)

@anlambert: are you proposing to remove it from everywhere or only from www.s.o ?

As an addendum to this: it should still be possible to provide an XML file with metadata for all but the simplest cases. What we want to optimize for is the case in which only the mandatory metadata are available and, in that case, offer a CLI alternative instead.

For file paths it would be nice to also support steps that use usual file/dir names foo/bar/baz, as a more readable alternative to number-based steps.

In T808#30140, @nahimilega wrote:

Now the problem is base url and the api token for each phabricator is different so I am not able to understand how to deal with this?
Can anyone please help me?

This is intended, because there is no guarantee that the Git repository accessible via an URL with a trailing slash will be the same of the one accessible at the same URL without the trailing slash. Same argument goes for all other examples you mention.

That is by design (although, admittedly, not really nice). More than "fixing" this specific issue, we might consider revamping/uniforming the general way of presenting sub-sites. But that is not gonna be just a fire-and-forget logo fix.

To clarify: "assignment" of tasks to specific people is something only us, Software Heritage maintainers, do. Hence I'm de-assigning the issue from @01shobitha.

I've nitpicked only about section naming/intro and some style, the rest LGTM.

• swh-weekly-report: new helper to write weekly reports
• swh-weekly-report: split generic code to swhphab.py
• swh-weekly-report: further refactoring/clean-up against swhphab.py
• swhphab.py: do not crash when printing summary of repo-less diffs
• swhphab.py: include status when printing task summaries
• swh-weekly-report: filter on committer date
• swh-weekly-report: preserve iterators and port to current Phabricator
• swh-monthly-report: helper script to draft monthly activity team reports
• swh-monthly-report: filter on committer date

• swh-weekly-report: preserve iterators and port to current Phabricator

Oups, sorry, didn't mean to accept this, only to remove myself from reviewers.
I'll let @anlambert finish the actual review.

In D1295#27649, @zack wrote:

or, actually, we can just also add a fulltext index to URLs and be done with it https://www.postgresql.org/docs/11/textsearch-intro.html#TEXTSEARCH-MATCHING

In D1295#27648, @zack wrote:

@anlambert given we have a trigram index on origin URLs, have you ever tried to use the various similarity operators document at https://www.postgresql.org/docs/11/pgtrgm.html instead of generating all possible permutations for regexs?
I'm assuming (probably too naively) that you can just do a big select on the URLs, sorting by similarity and possibly filtering on a threshold to return meaningful results. But it's not like I've actually tested it…

@anlambert given we have a trigram index on origin URLs, have you ever tried to use the various similarity operators document at https://www.postgresql.org/docs/11/pgtrgm.html instead of generating all possible permutations for regexs?
I'm assuming (probably too naively) that you can just do a big select on the URLs, sorting by similarity and possibly filtering on a threshold to return meaningful results. But it's not like I've actually tested it…

• swh-monthly-report: helper script to draft monthly activity team reports
• swh-monthly-report: filter on committer date

• swh-weekly-report: filter on committer date

Sure, just go ahead: there is no need to "reserve" tasks as a prerequisite to work on them. Just submit a diff against the lister repo as a diff when you've something ready to review :-)

• swhphab.py: do not crash when printing summary of repo-less diffs
• swhphab.py: include status when printing task summaries

• swh-weekly-report: further refactoring/clean-up against swhphab.py

• swh-weekly-report: split generic code to swhphab.py