Pattern idea: Common metadata format to aid discovery of Inner Source projects
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- github, gitlab
- Bereich
- developer-experience, tooling
Rechercherichtung
Beginne damit, die in diesem Issue vorgeschlagenen YAML-Felder zu prüfen und die unter Prior art verlinkte GrimoireLab projects file und Eclipse Foundation initiative zu vergleichen. Berücksichtige die Alternative mit Source-Control-Metadaten neben einer Repository-Datei; abgeschlossen ist die Aufgabe, wenn ein vereinbartes Format oder eine klare Entscheidung, keines zu definieren, erreicht wurde.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Following on from a conversation in the ISC Slack, would a metadata file added to Inner Source repos in source control (e.g. inner-source.json or inner-source.yaml) aid discovery of Inner Source repos within an organisation? If so, should we define a common format for this metadata?
Alternatively, should this information be derivable from your SCM tool (GitHub/GitLab/Bitbucket etc.)? This would negate the need to add a file to each inner source repo in your organisation.
One suggested format:
# description should be one paragraph
description: This is where you describe the purpose to your users.
Is this a component library, is this a template project, what
benefit is there to me if I use this library in my own project. You
Could even say something about how the project is versioned here.
# github pages or a conflunce link by default
# could be a readme for the project
documentation: https://github.com/InnerSourceCommons/InnerSourceLearningPath/
# technologies used
technologies: Javascript, React, Graphql, etc..
# comma separated list, name <email> (url)
maintainers: Barney Rubble <brubble@flintstones.net> (http://barnyrubble.tumblr.com/)
Prior art:
- Vorherrschende Sprache
- HTML
- Sterne
- 853
- Forks
- 206
- Ø Merge
- 1 T. 23 Std.
- Gemergte PRs (30 T.)
- 2
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus InnerSourceCommons/InnerSourcePatterns
-
community metrics
InnerSourceCommons/InnerSourcePatterns#935 · 1 zugewiesene Person ·
-
community metrics
InnerSourceCommons/InnerSourcePatterns#934 · 1 zugewiesene Person ·
-
community metrics
InnerSourceCommons/InnerSourcePatterns#922 · 1 zugewiesene Person ·
-
community metrics
InnerSourceCommons/InnerSourcePatterns#921 · 1 zugewiesene Person ·
-
community metrics
InnerSourceCommons/InnerSourcePatterns#915 · 1 zugewiesene Person ·
Alle Issues in InnerSourceCommons/InnerSourcePatterns
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
nightscout/nocturne#1424 ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Offenarea: repo bug perceived difficulty: 2
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
impl detach for native Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
paritytech/zombienet-sdk#591 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
mruangutai/harness#1897 ·