Proposal Schema for contribute.json

contribute.json

{
    // required
    "name": "Name of the project. (e.g. Bedrock)",
    "description": "Awesome website of sweetness",
    "repository": {
        "type": "git",
        "url": "https://github.com/mozilla/bedrock"
    },
    
    // optional
    "urls": {
        "wiki": "https://wiki.mozilla.org/Mozilla.org",
        "docs": "http://bedrock.readthedocs.org/",
        "mailing-list": "https://www.mozilla.org/about/forums/#dev-mozilla-org",
        "irc": "irc://irc.mozilla.org/#www",
        "introduction": "https://wiki.mozilla.org/Webdev/GetInvolved/mozilla.org",
        "tests": "https://ci.mozilla.org/job/bedrock/",
        "bugs-list": "https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&product=www.mozilla.org",
        "bugs-report": "https://bugzilla.mozilla.org/enter_bug.cgi?product=www.mozilla.org&component=Bedrock",
        "bugs-mentored": "https://bugzilla.mozilla.org/buglist.cgi?f1=bug_mentor&o1=isnotempty&query_format=advanced&bug_status=NEW&product=www.mozilla.org&list_id=10866041",
        "deployed-prod": "https://www.mozilla.org",
        "deployed-stage": "https://www.allizom.org",
        "deployed-dev": "https://www-dev.allizom.org"
    },
    "keywords": [
        "python",
        "less-css",
        "django",
        "html5",
        "jquery"
    ]
}

This is a first draft schema. Please suggest changes to key names or structures and we can move on from here.

add irc channel?

requiring urls: prod/stage/dev requires that this kind of thing exists or is applicable to that project. Not everything's a website.

So many times, people that aren't intimate with the project don't care what bugs it has but where to file a bug. But people who want to contribute what to list bugs. So we need both. How about:

{
...
  "bugs": {
    "file": "https://bugzilla.mozilla.org/enter_bug.cgi?product=www.mozilla.org&component=General",
    "list": "https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&product=www.mozilla.org"
 }

What word is best "file" or "submit"?

-1 on "getinvolved"
+1 on "irc"

How about "keywords" instead of "technologies"? I think I would still put in things like "jquery", "flask", "postgresql" in there.

-1 prod/stage/dev urls
-1 getinvolved
+1 irc
+1 keywords > technologies

report > file/submit ?

-1 wiki
+1 adding a URL to tests (Travis, Jenkins, etc)
+1 moving all urls in urls array with optional values:

{
    // required
    "name": "Name of the project. (e.g. Bedrock)",
    "description": "Awesome website of sweetness",
    "repository": {
        "type": "git",
        "url": "https://github.com/mozilla/bedrock"
    },
    // optional
    "urls": {
        "docs": "http://bedrock.readthedocs.org/",
        "mailing-list": "https://www.mozilla.org/about/forums/#dev-mozilla-org",
        "bug-list": "https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&product=www.mozilla.org",
        "bug-submit": "https://bugzilla.mozilla.org/enter_bug.cgi?product=www.mozilla.org&component=General",
        "irc": "irc://irc.mozilla.org/#www",
        "tests": https://travis-ci.org/mozilla/bedrock
    },
    "keywords": [
        "python",
        "less-css",
        "django",
        "html5"
    ]
}

Thanks all. Made some updates. Moar feedbacks plz.

I like contributor-guide as a replacement for introduction.

I don't think the deployed-* keys in urls works out well. Perhaps an optional websites or environments section:

{
  "websites": {
    "production": "https://www.mozilla.org",
    "staging": "https://www.allizom.org",
    "development": "https://www-dev.allizom.org",
    "demo1": "https://www-demo1.allizom.org"
  }
}

That way it's flexible to different environment setups and can support extra non-standard environments without parsing the keys much.

That would be useful to also have a "license" field.

Also, in case there is no mailing-list, should we have an "email" field?

If the repository url is worth pulling into its own block, it should probably point to the .git url so that it can be semantically and functionally different from the other (web) urls.

If we had "license" that should go under the "repository" container. The project doesn't have a license, the code does.

If the repository url is worth pulling into its own block, it should probably point to the .git url so that it can be semantically and functionally different from the other (web) urls.

I disagree. The ".git url" is for doing a git clone, no? The web url is more useful. Issues, README, etc.

-1 on a massive container for "urls". For example, why isn't the resposity->url key part of urls->repository.

Instead of

urls->deployed-stage, urls->deployed-dev

I would much rather see

deployed->stage, deployed->dev

big +1 on the new "keywords" section. I love that because if your skill is "flask" and "angular" that's most likely how you're going to search for projects to contribute to.

Do we even need deployed in there? Why not just

urls->stage, urls->production

I would have inferred that this is where code for those branches/tags/whatnot is deployed.

@peterbe I think the reason repository is not part of urls is because it is mandatory, and @pmclanahan wanted to keep all of those together in one place.

Also, might something like this work?

https://gist.github.com/ossreleasefeed/e0c52e9f1dac8bff943d/ff0821aaf35fcb39b34dcc2874379933a38a4498

perhaps even break out bugs into it's own group?

https://gist.github.com/ossreleasefeed/e0c52e9f1dac8bff943d

Some thoughts;

1. wiki - perhaps this should be homepage, (im stealing from package.json) but wiki seems tech dependent the idea here is where is the project hub.
2. introduction - this seems weird to me, this should be part of the project homepage or docs. Not sure if it's important or obvious enough to be in this.
3. +1 to https://gist.github.com/pmclanahan/a162224376ca110b4a40#comment-1270257 bugs{} me likes this approach.

Generally looks good, I like keeping this abstracted from our current tech choices (wiki bugzilla) and my comments are mostly around that.

I've created a real repo for this: https://github.com/mozilla/contribute.json

Let's continue the discussion there in issues or PRs. I'm finding it harder to follow the discussions here, and we can segment them into issues with specific areas there.