Template talk:Infobox software: Difference between revisions

RFC Question: Should we add a "source code repository" field to the infobox?

Caveats:

• It could go against WP:EL that says links that can be found as part of official website should not be included in the article.
• Doing so can make the infobox long and unwieldy. Sometimes, like in the case of Signal (software), there are four or five links. The External Links section is a better place.
• It is technical information that is no readily usable to every reader. Only programmers willing to participate in development need ready access to such links.

Best regards,
Codename Lisa (talk) 08:02, 4 September 2016 (UTC)[reply]

Place your verdicts here. Start each verdict with Oppose or Support as needed. This section is moderated, meaning non-verdict items will be moved to discussion section.

1. Oppose for the three reasons mentioned in Caveats section. Best regards, Codename Lisa (talk) 08:02, 4 September 2016 (UTC)[reply]
2. Support as original proponent. To prevent polluting this section, I'll add my reasoning in the discussion section, so I can address each raised caveat individually. --Waldir ^talk 09:57, 4 September 2016 (UTC)[reply]
3. Support as primary maintainer of the Source code repository property in wikidata, because it is a primary source of information that allows verification of licenses, authors, inception date etc. It is often difficult to find from the official website. The poll proposal is negatively biased (does not show any expected benefits) and reflects a single point of view. Dachary (talk) 08:42, 7 September 2016 (UTC)[reply]
4. Support as an interested consumer of this information. Having wikipedia-curated information about where to find source code of a given (FOSS) software would be invaluable. --Zacchiro (talk) 08:57, 7 September 2016 (UTC)[reply]
5. Support I think it is an rather essential part of FOSS, and people reading these pages probably have an affinity to visit the source code pages. A shortened URL would probably be good. Instead of a key-value pair maybe just display the link with the label "Source Repository"? --Tobias1984 (talk) 20:14, 7 September 2016 (UTC)[reply]
6. Support, as the primary source of information about software. To avoid polluting the infobox only one URL should be allowed, preferably one leading to the OS-independent root of the main mirror. If several are necessary, only short name of the target and not the full URL should be visible in the infobox. “WarKosign” 07:37, 13 September 2016 (UTC)[reply]
7. Indifferent The caveats seem fairly mild and so do the needs. Sorry I can't be more definite, but it is not a facility that I am familiar with. I recommend that anyone who cares enough proceed rather than chewing the subject to rags; the discussion so far already exceeds any reasonable investment in such a facility. If nothing horrible happens the naysayers could best swallow and look pleasant. JonRichfield (talk) 08:57, 14 September 2016 (UTC)[reply]

I don't think the caveats mentioned above are as problematic as to warrant removal of the field. Specifically:

1. "It could go against WP:EL": WP:EL is naturally a sensible and mature guideline, but in this particular case I believe WP:IAR applies, because including the source code link in the data infobox for articles covering software increases the encyclopedic value of the project, which is the primary aim we ought to strive for.
2. "Doing so can make the infobox long and unwieldy": The size of the infobox entry can be managed in various ways that don't involve outright getting rid of the field: from shortening of the field name (say, to "source code" or "repository"), to manually providing shorter values in articles where the content returned by Wikidata is undesirably long, to directly editing the Wikidata item so that one of the repo entries is marked as preferred, to full-on implementing a more general form of Template:URL by improving its Lua module based on Module:Official website so that it gains the ability to pretty-print multiple URLs. Only the latter of these options requires more than a quick fix, so I wouldn't say this is particularly problematic.
3. "It is technical information that is no readily usable to every reader": We could make the same argument about the license field, or others. Ultimately, we must consider that the audience of FLOSS articles (the only ones where this field will appear) is likely composed of a greater percentage of tech-savvy users and/or those concerned/acquainted with the concepts related to openly-licensed software and collaborative development projects. In this light, I'd argue that it's a disservice to the reader to deprive them from this relevant information which otherwise would not be presented in a predictable, consistent format.

For these reasons, I stand by my initial position that a repository field is a net positive in this infobox. --Waldir ^talk 10:12, 4 September 2016 (UTC)[reply]

Some smaller projects don't have a website other than their repo. How would those be handled if the repo parameter is removed? Matt Fitzpatrick (talk) 03:21, 5 September 2016 (UTC)[reply]

|website= —Codename Lisa (talk) 09:15, 5 September 2016 (UTC)[reply]

Just to offer the "other side of the coin", is there any reason why the infobox couldn't be coded and documented like this? --RexxS (talk) 18:04, 5 September 2016 (UTC)[reply]

That can already be done by filling a custom value in the repo parameter. To make it work automatically using data from Wikidata would be more involved. Maybe there could be a qualifier to the repo statement indicating the repo name? I'm not sure, but if so, we could access that qualifier using a custom module and generate the link automatically. --Waldir ^talk 21:10, 5 September 2016 (UTC)[reply]

Looking at 'what links here' from source code repository URL (P1324), almost all of the urls contain an identifying string between the penultimate and final / that could be used as a label (with the exception of Firefox (Q698)). When pulling the data from Wikidata, it would be relatively straightforward in Lua to extract that identifying string and construct a hyperlink using that for the text. In the odd case where it is blank, then the full url could be returned. Update: actually, the repository for Firefox was pointing to the root; I've fixed it and now it reads https://hg.mozilla.org/firefox/ and would fit the algorithm. --RexxS (talk) 21:40, 5 September 2016 (UTC)[reply]

Isn't that too brittle, though? e.g. the Wikidata item's URL is https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FWikidata.git, so the extracted string would be either "extensions" or "summary" (depending on whether we decode percent-encoded url characters), neither of which would be a useful label. Or am I misunderstanding your proposal? --Waldir ^talk 22:59, 5 September 2016 (UTC)[reply]

Whenever we fetch data from Wikidata, we have to accept that (1) the stored values were not designed just for our use and (2) the constraints on data values are rather weak. The result is that it's quite difficult to write code that is guaranteed to cover all cases. In my experience it's best to use code that handles most of the cases as simply as possible, and rely on the ability to override unwanted returned values by supplying a local value to the parameter. It's also worth checking when you find exceptions that the Wikidata value is actually the best, as I did with Firefox. If you follow https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FWikidata.git you actually arrive at https://phabricator.wikimedia.org/diffusion/EWDA/ which would be a much better value, imho.

Naturally, you can try to modify the way the value is stored on Wikidata, perhaps by adding a qualifier which would constitute the displayed text as you initially suggested. The initial problem there is that I can't see a good match for what we want among the properties available - perhaps official name (P1448)? The remaining problem then would be to persuade everyone adding a source code repository URL (P1324) url to add the qualifier, otherwise we end up having to add it ourselves - in which case I'm wondering why we would bother fetching the value from Wikidata rather than just using a local value? --RexxS (talk) 23:32, 5 September 2016 (UTC)[reply]

I don't think there is a way to automatically figure out a sensible short name for the repository. And I also do not see how that could be consistently maintained in wikidata. It's a nice idea though :-) Dachary (talk) 08:47, 7 September 2016 (UTC)[reply]

@RexxS: Yes, there is. According to MOS:COMPUTING, infobox links must be printer-friendly. But you can display as many of them as you link in "External links" section. I've already said WP:EL's angle against it, but let's call this a compromise I readily accept. Best regards, Codename Lisa (talk) 07:32, 6 September 2016 (UTC)[reply]

@Codename Lisa:MOS:WEBADDR: Certain areas of Wikipedia such as infoboxes require website addresses (URL) to be exposed in print. To maintain readability and conciseness, certain parts of the web addresses may need to be hidden or their shorter forms used. (my emphasis). Infoboxes, where space is at a premium, are not the places to put full urls. If you're worried about people printing the page out and losing the full url, then check the version of an article like aspirin that you get after clicking on "Printable version" in the left side toolbar. It has all of the external urls in the infobox expanded. It's not pretty on paper, but no information would be lost by using the scheme I suggest. Cheers --RexxS (talk) 15:28, 6 September 2016 (UTC)[reply]

My dear RexxS, you really need not bother with emphasizing; I know that part of MOS:WEBADDR like the back of my hand. The parts that you proposed to hide aren't those that MOS:WEBADDR sanctions. But that's really not my concerns. My concerns are those that I counted above. And really, being told that I am using a fallacious slippery slope argument doesn't give me the fuzzy feeling to withdraw my position without a step in the way of compromise from the opposition.

Best regards,

Codename Lisa (talk) 21:23, 6 September 2016 (UTC)[reply]

Please don't patronise me; you won't like my responses if you do that again. It's quite obvious that emphasis is required when you've ignored the very point that MOS:WEBADDR makes: Don't put long urls in infoboxes. The parts that I showed as hidden are precisely what WEBADDR requires. There's no need for long urls in infoboxes, and "printer-friendly" just isn't an argument, as I assume you've realised by now. I have no interest in seeing you withdraw your position; personally I am rather indifferent about whether there's a "source code repository" field in the infobox, although if pushed I'd probably prefer to see those in the External links sections, rather than extending an already lengthy infobox. Nevertheless - and I tried to put this politely first time - your illustration above is a misleading and deliberately contrived piece of nonsense. That's all I was drawing attention to. I hope I was clearer this time. Cheers --RexxS (talk) 23:58, 6 September 2016 (UTC)[reply]

Just for the peace of mind of anyone else reading this, I was trying to oppose politely, not patronize. Patronizing and other social unpleasantness is a waste of time to which I never commit.

Waldir, I would like your frank and honest comment on this: Do you also believe what I write is a "misleading" and "deliberately contrived piece of nonsense" and that I am harassing you by it? Please don't hold back, because if it is true, I will do every effort to make up for it. Thanks.

Best regards,

Codename Lisa (talk) 09:08, 7 September 2016 (UTC)[reply]

I've been deliberately avoiding reacting to aspects of the discussion that aren't focused on the objective facts under scrutiny and possible compromises, as that tends to carry out the conversation to less helpful, emotionally-charged, person-focused (rather than argument-focused) observations. But since you ask: I wouldn't put it in those terms, but I agree that the way the RfC's opening statement was presented didn't reflect an unbiased view of the discussion that preceded it (for instance, it used a worse-case example as if it were a typical one, and listed only downsides to the addition). I'd say that is indeed misleading, regardless of that effect being deliberate or not.

By the way, I wouldn't do this in a way that calls the attention of others (e.g in an unrelated discussion like this one), but again, following your prompt, allow me to comment generally on the tone of your comments in the interactions we've had so far: I tend to perceive from you a tendency to take actions and words as if directed to your person, or reflecting a power dynamic that is (at least from my part) not intended. Your comments about me being an admin ("But you are admin and that means I probably can do nothing about it.") are a prime example of this. That RexxS interpreted your comment as patronizing (and by the way, he also failed to refrain from escalating the discourse further) should have made you at least consider the possibility that your words were poorly chosen and could indeed have been interpreted that way, rather than merely denying the assessment. In fact, you have admitted to overreacting yourself, when we last conversed. I am afraid realizing this hasn't yet had the effect of preventing the same from occurring again. Please work on that, as the whole community will benefit from a less charged discourse. And everyone else: let's try to avoid escalating the discussion and aim for a calm and reasonable compromise, as we've all got better things to do, and we don't want to end up in XKCD for the wrong reasons, do we? :) --Waldir ^talk 10:30, 7 September 2016 (UTC)[reply]

@Waldir: That is not what I asked you to comment on. I asked you about MOS:WEBADDR and caveats, not any of this. Or that is what I received from a "misleading" and "deliberately contrived piece of nonsense".

As for the patronizing perception, I did consider it. You cannot tell because it happened in my mind. (I dismissed it as I find the reaction disproportionately hostile.) And as for you being an admin, everyone knows that reverting an admin's action done in admin capacity without just cause is wrong. Whatever else you have interpreted from my comment, please throw into the trash can. Finally, invoking connection to a conversation that happened over two years ago and suggesting I am still under the same misapprehension is a wrong that merely invites conflict. Best regards, Codename Lisa (talk) 10:56, 7 September 2016 (UTC)[reply]

A few loose points:

• My comments were meant in a general sense, not attempting to imply a personal grudge between us two (I certainly don't hold anything against your person, just against the way you communicate sometimes, as I attempted to expand above). I am sorry that my words didn't make this explicit to you.
• I was reacting to what I thought was the reason you mentioned me specifically: "Do you also believe what I write is a "misleading" and "deliberately contrived piece of nonsense" and that I am harassing you by it?". I seem to have misinterpreted what you were asking, but still believe what I said to be of some value -- I wouldn't "throw it in the trash can", to use your words, as I still think it is useful commentary for this discussion and others.
• "As for the patronizing perception, I did consider it. You cannot tell because it happened in my mind." -- I considered pointing out precisely this, but was already writing too much. The part I highlighted demonstrates the issue. You surely are aware of the increased difficulty of written communication in getting unverbalized thoughts across, so my suggestion is to give some more weight to this, and generally erring on the side of (polite) explicitness, just in case.
• Responding specifically about MOS:WEBADDR, since you insist that my opinion is particularly relevant (compared to other participants in this discussion): I believe RexxS is interpreting the rules correctly, and that his proposal holds both to the spirit and to the letter of that guideline.
• Finally: I disagree with every word of "deliberately contrived piece of nonsense" -- at best, they are unprovable assumptions, and at worst they are a personal attack which is explicitly repudiated by our community guidelines. --Waldir ^talk 11:24, 7 September 2016 (UTC)[reply]

Good. Finally we are on the same page. This RFC was seriously at risk of becoming the worst RFC in my life. MOS:WEBADDR is proponent of using the more succinct forms of URL when they are displayed in bare form. Since the proposition above contains hyperlinks not bare URLs, MOS:WEBADDR hardly applies to it. This is something I just noticed. MOS:WEBADDR doesn't say in link added to the infobox must be bare. It is an Infobox Software initiative to display a bare official website link. That's a good initiative, one that we can overlook. Best regards, Codename Lisa (talk) 17:42, 7 September 2016 (UTC)[reply]

The proposal above should be amended with the expected benefits of having the source code repository displayed in the infobox. The example infobox should be changed to reflect that a single link would be displayed since nobody supports the idea of displaying multiple links. An earlier version of the page has these suggested changes but they were reverted. Without these changes the reader is asked to give an opinion based on an incorrect display of the infobox and with none of the expected benefits. It is to be noted that the primary focus of the author of the poll is proprietary software and Windows in particular, even in his most recent activity. This does not change the validity of his opinions, but that calls for a special attention to represent the diversity of the interests of the readers by including the views of at least one person with a primary interest in Free Software articles. Dachary (talk) 10:11, 7 September 2016 (UTC)[reply]

Agreed. --Waldir ^talk 10:32, 7 September 2016 (UTC)[reply]

Excuse me? This isn't your message to agree or disagree. Not agreeing with the nominator is natural, but disrupting and subverting his message is outrageous. I never modify anyone's nominations in RFCs, AFDs, RFAs, RFBs, or ANEWs. Best regards, Codename Lisa (talk) 10:41, 7 September 2016 (UTC)[reply]

Question for Codename Lisa (talk): Have you ever built or tried building a software from its source code repo? If yes, please name them. — Preceding unsigned comment added by 95.156.216.107 (talk) 18:22, 7 September 2016 (UTC)[reply]

Irrelevant question, but the answer is yes. SVGOMG, Fraunhofer FDK AAC, Visual Studio Code. —Codename Lisa (talk) 18:14, 8 September 2016 (UTC)[reply]

What a suspicious question and answer. I wonder if @Mike V: would see any cause for concern? 98.244.77.73 (talk) 08:35, 9 September 2016 (UTC)[reply]

Probably accuses me of edit warring on another article on which I have no diff! I wonder what he says about you contribution history though. It smells harassment.

No regards, Codename Lisa (talk) 09:18, 9 September 2016 (UTC)[reply]

Johan Richer and Emmanuel Raviart both work for a catalog of software for the French government, which motivated their interest in supporting this proposal. Their existence is real, their interest is genuine, to the extent that they both participated in the french wikiconvention organized in Paris a few weeks ago. This information is easily verifiable with a search engine. But the author of this poll came to a different conclusion and opened a socketpuppet investigation which was ruled within 24h. No attempt was made to contact either of them. Immediately after the ruling, the author of the poll removed the support expressed by Johan Richer and Emmanuel Raviart. I noticed the edit and added a user comment to the socketpuppet investigation and I'm hopefull this wrong will be undone. Dachary (talk) 20:38, 8 September 2016 (UTC)[reply]

My friend, it is "sockpuppet" not "socketpuppet".

But come to think of it, how do you know these accounts belonged to Johan Richer and Emmanuel Raviart? Maybe an intelligent cheater took advantage of their names in choosing his account names. I mean, anyone can create an account named User:Bill Gates, User:Richard Stallman or User:Obama.

In any case, Eraviart parroted Jricher's statement word for word without adding a layer of thinking to it to see that it is patent-nonsense. That's meatpuppetry which is equally bad. (Patent-nonsense because WP:ELOFFICIAL is a part of WP:EL and does not override it. Moreover, when I said WP:EL I really meant WP:ELOFFICIAL. So, this is a reason to oppose not support.)

Best regards,

Codename Lisa (talk) 09:18, 9 September 2016 (UTC)[reply]

I know these accounts belong to Johan Richer and Emmanuel Raviart because we discussed about it the same day. You can see from their profile that both are very much invested in the topic at hand. And I hope we can turn this unfortunate first experience into something more positive. They both acted in good faith and do not deserve to be treated in this way. I understand some explaining is necessary because a technicality (same IP and same comment, new comer mistake) made them look suspicious. Now that it is out of the way, asking even more proof and justifications is unnecessary. Dachary (talk) 11:13, 9 September 2016 (UTC)[reply]

Note: this summary is intended to be neutral and should reflect the diversity of point of views. It has been added because the author of the Rfc was unresponsive to suggestions to modify the summary of the Rfc to be neutral. Dachary (talk) 11:30, 9 September 2016 (UTC)[reply]

Benefits:

• It is the primary source of information for a number of facts about the software. For instance the license, the authors, the inception date.
• It significantly helps every reader and editor to verify facts about the software.
• It is frequently non trivial to find from the official website.

Caveats:

• It could go against WP:EL that says links that can be found as part of official website should not be included in the article.
• It is technical information that is no readily usable to every reader. Only programmers willing to participate in development need ready access to such links.

Dachary (talk) 14:17, 9 September 2016 (UTC)[reply]

It is your point of view and as non-neutral as it can get. It has the following problems:

1. "It is the primary source of information for a number of facts [...]" If it is a source, it must go to the citations section and cannot appear as a standalone external link.
2. "It significantly helps every reader [...]". So basically, WP:IJUSTLIKEIT. Veteran Wikipedians get inoculated against the allegations of "It significantly helps" unless it is proven or displayed. Virtually every spammer claims his addition significantly helps! Furthermore, WP:NOT has it that Wikipedia deliberately avoid being a collector of thousands of useful things; includes WP:NOTLINK.
3. "It is frequently non trivial to find from the official website." In that case each link requires a source! Contents without source are challenged or deleted, meaning that I am at liberty to challenge or delete these statements that come from WikiData without a source. I would be at the right to suppress the addition of this field because it adds potentially unreferenced non-trivial information. Seriously, how do you call this a benefit?
4. The demo infobox is not faithful demonstration of how Waldir made it look like, causing me to start this RfC. One of the purposes of this RfC is to mitigate this issue. This is your idea and one of the ideas, but:
   1. It contains one link only and does not demonstrate what catastrophe would occur if multiple come from Wikidata.
   2. The [[source code repository|source code]] link in it is a violation of WP:SUBMARINE. This problem didn't exist in the Waldir version.
5. "because the author of the Rfc was unresponsive to suggestions to modify the summary". Hint: Try easing off on ad hominem comments and try not censoring other people's messages. Aside from that, you seem to have trouble understand what is the purpose of an RFC: For the author to request comment on his opinion! You want to change my opinion. If you change it won't be a request for comment on my opinion.

Best regards,

Codename Lisa (talk) 13:13, 9 September 2016 (UTC)[reply]

The caveats are not my point of view, they are copy/pasted from your point of view, which makes the section above neutral as it represents a diversity of viewpoints. I would be more than happy to amend this section if someone feels an aspect is missing, regardless of the fact that I agree or disagree with her/is point of view. I did not include the caveat where you describe the infobox layout that nobody supports as the desired layout because it does not convey any information or opinion, it relates to a bug in an earlier implementation that no longer exists and has no relevance in this discussion. In a Rfc the statement and summary should be neutral and brief, not opinionated. Dachary (talk) 20:52, 9 September 2016 (UTC)[reply]

Are you talking to someone else who is not here? I didn't even mention the caveats section.

But you are not neutral. Between everything you have done so far, like your personal attacks, filling an ANI case against me, digging dirt on me, etc., you are the last person in the universe I would believe to be neutral. —Codename Lisa (talk) 08:07, 10 September 2016 (UTC)[reply]

In the spirit of going back to a more productive dialog I will let the non factual comment above, the removal of my edit and the modification of another edit slide. I could dispute them but that would bring nothing to the discussion. Let's be grown ups and move on, shall we ? Dachary (talk) 10:59, 11 September 2016 (UTC)[reply]

Note: this summary is intended to be neutral and should reflect the diversity of the point of views expressed in the above discussion. If a benefit, caveat or implementation detail is missing or misrepresented, please let me know and I'll update it.

Benefits:

• Including the source code link in the data infobox for articles covering software increases the encyclopedic value of the project (see WP:IAR).
• The audience of FLOSS articles (the only ones where this field will appear) is likely composed of a greater percentage of tech-savvy users and/or those concerned/acquainted with the concepts related to openly-licensed software and collaborative development projects. It would be a service to these readers to present them with this information which otherwise would not be presented in a predictable, consistent format.
• It is the primary source of information for a number of facts about the software. For instance the license, the authors, the inception date.
• It helps every reader and editor to verify facts about the software because it contains most of them.
• It is frequently non trivial to find from the official website. If it was, it would be redundant with the official website URL.

Caveats:

• It could go against WP:EL that says links that can be found as part of official website should not be included in the article.
• It is technical information that is no readily usable to every reader. Only programmers willing to participate in development need ready access to such links.

Implementation notes:

• If multiple source code repository links exist and none has a preferred rank, no link is displayed because they would clutter the display.
• If a quick fix is not enough, more general form of Template:URL by improving its Lua module based on Module:Official website could be implemented to handle the various cases.
• If the URL is undesirably long (MOS:WEBADDR), it can be manually overriden by a shorter URL, as can be done with the official website.
• The label is shortened from Source code repository to Source code: both have the same meaning in this context and comply with the recommendation of MOS:SUBMARINE.

Dachary (talk) 08:56, 12 September 2016 (UTC)[reply]