Enhance the nuspec - first wave

[ferventcoder]

Allow the following extra metadata into the nuspec:

• projectSourceUrl
• packageSourceUrl
• docsUrl
• mailingListUrl
• bugTrackerUrl
• replaces
• provides
• conflicts

This is chocolatey-archive/chocolatey#172 and is related to https://github.com/chocolatey/chocolatey.org/issues/101

[ferventcoder]

The second wave is #325.

[dtgm]

:) ... I see what you did there.

[dtgm]

forumUrl ?

[ferventcoder]

mailinglisturl would be sufficient to use the same as you need for forumUrl?

[pyhedgehog]

Shouldn't MailingListUrl contains something like "mailto:software-list@example.com?subject=subscribe"?
If yes, then ForumUrl should be something different (for example "http://www.example.com/mail-archive/software-list/").

[RichiCoder1]

I assumed that mailingListUrl would point to a web page for accessing archives and subscribing.

[pyhedgehog]

Then we need something like MailingListSubscribeUrl and MailingListUnsubscribeUrl?
From my point of view this is overkill - at least I'm almost always click on "Software Site" and search for wiki/source/issues/discussions urls there. Site will be updated sooner that package will be released.

[ferventcoder]

@pyhedgehog you are leaning towards what would be overkill, yep. The idea behind mailingListUrl if folks wanted to use it is what @RichiCoder1 mentioned.

[dtgm]

mailinglisturl would be sufficient to use the same as you need for forumUrl?

@ferventcoder in spirit I agree in practice, let's see...

$ ls */*.nuspec | wc -l
796
$ grep -i "\[Mail" */*.nuspec | wc -l
27
$ grep -i "\[Forum" */*.nuspec | wc -l
131
$ for i in $(grep -i "\[forum" */*.nuspec -l); do grep -i "\[Mail" $i; done | wc -l
17

Just mulling over it, mailingListUrl and forumUrl are two different methods of the same overarching theme; engagment of the community with each other. It's just the mechanism of which that happens uses different technology; email and BBS in this case.

From my inventory, "forum" is more popular in practice. And drawing on history, probably more familiar with users because the idea already permeated the world with the Roman empire. A forum is just a public place to gather and engage. Mailing list to me has a more specific purpose.

Also, just fyi, there's IRC to round out the old-school technologies...

$ grep -i "\[IRC" */*.nuspec | wc -l
12

... but would probably better be labeled as chatUrl to keep up with newer services like Gitter.im would fall under.

So by just my packages, only 17 would be affected by only having one discussionUrl. But my vote would be forumUrl for user familiarity and it is more congruent by actual conditions.

Also, I will chime in my reason for including more metadata in my packages. Chocolatey lets you automate installs, but also removes needing to hunt and peck for clicky things. I figure, why not extend this to the websites themselves by just grabbing some of the links while I'm scraping? There are more uses than just having a convenient hyperlink when you need it. By being a full-fledged package manager with standardized XML data, you could imagine doing a search for all packages you have installed with chatUrl so you can quickly get a list to add to your multi-protocol chat client. Of course the URLs can change and need to be updated, but I don't think that's too common. Also, it lets you count what technology software developers are using so you can make the right decision when it comes to choosing if mailingListUrl is the right choice ;)

Eventually the metadata becomes overwhelming and that becomes a presentation thing or the metadata becomes sentient and grows into actionable events like @pyhedgehog noted.

[dtgm]

I should also mention that I didn't start collecting this metadata into the nuspec from the beginning. I must have been at least through several hundred packages before I realized what I was doing and it may be useful to grab. It dawned on me when I found I was having difficulty more often than I liked finding a program's forum. So 131 only indicates the minimum amount of packages with forums.

Here's what I've been grabbing:

#### Documentation
* [Features]() -- because <description> is limited to 4000 characters ;) also description should be more about how it installs but I haven't had time for that as so many packages on chocolatey were laying stagnant I thought it better to fix those up first (also made me realize why it is important to collect this stuff; at some point I intend on coming back to get information from these places to make the package more flexible, I want to make it as easy as I can for myself)
* [Screenshots]() -- meh, but so many programs designate a section for them
* [FAQ]() -- required; no one RTFM... this is the one additional chocolatey tag absolutely needed, faqUrl
* [Wiki]() -- sometimes different site entirely, or a project is mirrored on gh from sf, wiki on gh is nice, sf is like wikawhaaat?
* [Manual]() -- ✔

#### Community
* [Forum]() -- previous post
* [Mailing list]() -- ✔
* [Facebook]() -- meh, kids
* [Google+]() -- meh, kids
* [Twitter]() -- meh, kids

When software is client for a web service
#### [Privacy Policy]()

The next are all very related, and sometimes predictable, but also sometimes not. I try not to spend too much time, but sometimes a changelog isn't in the repo for whatever reason, or is formatted poorly and the web version gets rendered more readable.

<releaseNotes>
#### Program
* [News]() -- web RSS, aka blog ... not always release notes
* [RSS feed]() -- I really want there to be rssUrl, but I don't think that is a popular opinion... :(
* [Release log]() -- list of version/date, useful for processing later (for me)
* [Roadmap]() -- do you have a plan? no plan, no future.
* [Changelog]() -- ✔
* [Known issues]() -- ✔
* [Source code]() -- ✔

I try to not be overwhelming, but different people can see different uses for stuff. And I'm not sure why people dislike too many tags in XML. Just because it is in the chocospec doesn't mean it has to be rendered by your package manager, or in most cases, the web gallery.

[RichiCoder1]

I can imagine not surfacing most of these to end users of ChocoGUI except for as an advanced option.
Both docsUrl aka FAQ/Wiki and mailingListUrl aka Community URL seem obvious additions to display, though. I could only see supporting more specific social and community likes through the description.

[alexchandel]

@ferventcoder Should projectSourceUrl point to a website hosting the source (e.g. a GitHub page) or the actual .tar.xz containing the source?

[ferventcoder]

Website hopefully, but if that is not available, a secondary tar for download is possibly okay.

[ferventcoder]

The original intent is a url to a website.