There was some hassle installing it with a german package server:

https://www.mediawiki.org/w/index.php?title=Chemical_Markup_support_for_Wikimedia_Commons/office_desk&oldid=984412#Odd_stuff

Any news?

• There is a proof-of-concept running on WMF-Labs: http://mol.wmflabs.org/
• There is an overwhelming support at Wikimedia Commons for this feature:
  • https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Support_for_Chemical_table_files
  • https://commons.wikimedia.org/w/index.php?oldid=128540415#Support_for_Chemical_table_files (permalink)
• There is support by power users on the mailinglist:
  • http://lists.wikimedia.org/pipermail/commons-l/2014-July/007261.html
• There is interest by Wikipedians of relevant projects (their current objection is just that the output doesn't look like their standards but this can be easily corrected with some command line switches):
  • https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Chemistry#Support_for_Chemical_table_files
  • https://de.wikipedia.org/wiki/Wikipedia:Redaktion_Chemie#Strukturformeln_f.C3.BCr_das_Wiki
• I would be glad if I could have the Okay to use it in a month.

I am still around @csteipp and would invest time in this project again if I see that something is moving from the WMF side (e.g. this security review).

@Gilles, is multimedia thinking about supporting this?

I did an initial look at indigo-depict, and the code quality didn't look extremely promising, but if we have some internal support to fix any bugs we find, then there's a much higher chance we can deploy this.

What is internal support support exactly and is there a gold standard for evaluating code quality? Test coverage, coding conventions, documentation and legibility are certainly factors but I have no clue how it looks from the perspective of a security software engineer.

In T66548#960192, @csteipp wrote:

@Gilles, is multimedia thinking about supporting this?

I did an initial look at indigo-depict, and the code quality didn't look extremely promising, but if we have some internal support to fix any bugs we find, then there's a much higher chance we can deploy this.

I think our work should be first and foremost to support volunteer contributions, so yes, we will provide that kind of support if needed. @Rillke has put a lot of effort in this project that I wouldn't want to see go to waste.

@sbassett Does Community-Tech need to do something here?

@Niharika - I believe I tagged Community-Tech as it was thought that they might be a viable champion/owner of this project, when the Security-Team recently discussed this task. If that's not the case, then we can remove the tag.

In T66548#4881474, @sbassett wrote:

@Niharika - I believe I tagged Community-Tech as it was thought that they might be a viable champion/owner of this project, when the Security-Team recently discussed this task. If that's not the case, then we can remove the tag.

Yeah, Community Tech gathers projects from the Community Wishlist survey and we already got a bunch of projects on our roadmap this year. Sorry, we won't be able to take this on.

@Ramsey-WMF @MarkTraceur -

Hey Multimedia Team. We have this long-lingering review of an old Google-Summer-of-Code project where we'd been asked to review the indigo-depict dependency. Given the elapsed time here and that there most likely isn't a current champion of this extension (as a code steward or for production deployment) the Security-Team would like to propose closing this as declined by April 15th, 2019. If the above assumptions are incorrect and the Multimedia Team (or another team/individual) would like to become a steward for this extension with the goal of deploying to production over the next quarter or two, we can definitely see where we're at and reschedule this review. Thanks.

(n.b. Multimedia, while not perfect, seemed like the closest match as a potential advocate for this extension)

Unfortunately, this code isn't something we can support either (no C programmers on the team, overloaded with SDC now, etc.)

In T66548#5098802, @sbassett wrote:

@Ramsey-WMF @MarkTraceur -

Hey Multimedia Team. We have this long-lingering review of an old Google-Summer-of-Code project where we'd been asked to review the indigo-depict dependency. Given the elapsed time here and that there most likely isn't a current champion of this extension (as a code steward or for production deployment) the Security-Team would like to propose closing this as declined by April 15th, 2019. If the above assumptions are incorrect and the Multimedia Team (or another team/individual) would like to become a steward for this extension with the goal of deploying to production over the next quarter or two, we can definitely see where we're at and reschedule this review. Thanks.

(n.b. Multimedia, while not perfect, seemed like the closest match as a potential advocate for this extension)

@sbassett: Assuming that the Application Security Reviews tag was removed accidentially when declining this security review request

@Aklapper - Our standard has been to remove Application Security Reviews (or Security-Team-Review-Active) when we close a request as declined or invalid, since those projects represent requests that will actually be reviewed at some point. I suppose it doesn't really matter, since any closed task is set to disappear from those workboards, which is the important piece.

@sbassett: Removing the Application Security Reviews tag makes it impossible to get a list of all [non-open] review requests, and harder to find an old declined task in the future (as one would search for review tasks in the review project). I'm curious which problem is solved by removing such categorization information, but probably not in this very task (it's a bit off-topic). Note that you can filter the workboard view by changing " All Tasks" to " Open Tasks" in the upper corner.

@Aklapper - Yeah, that's fine. Our workboards for Application Security Reviews and Security-Team-Review-Active default to only show open tasks (I believe - or at least that's my default) which is a perfectly acceptable solution.