#326 delete the distribution page and remove it from footer

[magdmartin]

closes #326

[netlify]

✅ Deploy Preview for openrefine-website ready!

Name	Link
🔨 Latest commit	02bac3c
🔍 Latest deploy log	https://app.netlify.com/sites/openrefine-website/deploys/669e73b8e1c24e0008f60e19
😎 Deploy Preview	https://deploy-preview-357--openrefine-website.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[wetneb]

Note: you need to say "Closes #326", not "Close #326", for the PR to be correctly associated to the issue

[Abbe98]

The forum discussion and the issue both suggest stopping inviting people to fork OpenRefine, this pull request, however, suggests dropping information on existing distributions. How does this benefit OpenRefine users?

[magdmartin]

Currently, the distribution page references outdated distributions that are not maintained. Ontotext Refine 1.1 is the most up-to-date, but it is nearly two years late by packaging OpenRefine 3.6.1. Another good example is the LODRefine distribution, which was widely advertised in 2013 and gained some traction. However, users never benefited from improvements made to OpenRefine past the 2.6 version and created a lot of confusion when providing support.

From a developer perspective, advertising other distributions can also be considered an implicit invitation to fork. I also open OpenRefine/OpenRefine#6725 to update the CONTRIBUTING.md on the OpenRefine/OpenRefine repo.

[tfmorris]

OntoText should be excluded for the simple fact that they're violating our license. We shouldn't be providing promotion to organizations which don't respect our intellectual property rights.

For the others, the unsupported packages are primarily of historical interest at this point if they haven't been updated in a decade or more. Perhaps a middle ground would be to list the date they were last updated.

@Abbe98 what value do you see this list providing to users?

[wetneb]

@tfmorris in which ways do OntoText violate the license? I would assume that's just an oversight given that they are not hiding the fact that OntoRefine is built on OpenRefine. It's probably something they'd be happy to fix.

@Abbe98 by listing forks as "distributions" we are creating some ambiguity which is

• deceitful to users because they might assume that those forks are somehow vetted by or coordinated with the OpenRefine project. I think the word "distribution" is more suitable for, say, the Chocolatey, HomeBrew or Debian packages.
• deceitful to potential fork authors, because it advertises OpenRefine as something that's intended to be forked. They might understand it as offering some stability guarantees which we don't actually have. For instance, in the documentation about installing extensions in OntoRefine, one can read "OpenRefine, the framework which Ontotext Refine is build upon" -> that's an unfortunate misunderstanding: as far as I am concerned, I don't consider OpenRefine to be a "framework" with which applications can be built, but an application on its own.

[tfmorris]

https://github.com/OpenRefine/OpenRefine/blob/d29a6e125d4b938766f2de9e1ca83d0e66fcc888/LICENSE.txt#L8

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

When the CS&S lawyers contact them, they should also get them to use the correct name for OpenRefine (ie not "Open Refine")

[wetneb]

I personally wouldn't send lawyers after them but rather contact them directly and ask them in a friendly way if they could correct this oversight.

Personally, I don't want the removal of this page and the associated discussion to be perceived as a war on our forks: as far as I am concerned it's totally fine to fork OpenRefine. It's just a bit awkward of us to advertise forks with this "distributions" page.

I would of course find it better if people could instead contribute upstream and/or write extensions, but for this to happen more consistently we have quite a bit of work to do, both on our technical infrastructure (better extension system, ensuring more stability) and our social practices (better governance, more emotional intelligence and empathy).

[Abbe98]

I think this discussion illustrates that this change isn't well intended towards users and the overall ecosystem but rather comes from a few individuals wish to be in control of OpenRefine.

The original "discussion" and issue is about "stop inviting for new fork and distribution", this pull request isn't and attempting this with the given motivation is therefore deceitful. That said the original discussion might have been broader but that isn't even public so I don't think it should count.

[Ainali]

I think this discussion illustrates that this change isn't well intended towards users and the overall ecosystem but rather comes from a few individuals wish to be in control of OpenRefine.

The original "discussion" and issue is about "stop inviting for new fork and distribution", this pull request isn't and attempting this with the given motivation is therefore deceitful. That said the original discussion might have been broader but that isn't even public so I don't think it should count.

In my opinion, it is not deceitful, as this PR intends to remove the incentive for creating new forks and distributions by removing publicity for any of them (no one will be led to believe that creating one is so encouraged it will be listed on that page). (That was also all what we discussed in the meeting, there was no one who wanted "to be in control".)

[Abbe98]

I think this discussion illustrates that this change isn't well intended towards users and the overall ecosystem but rather comes from a few individuals wish to be in control of OpenRefine.
The original "discussion" and issue is about "stop inviting for new fork and distribution", this pull request isn't and attempting this with the given motivation is therefore deceitful. That said the original discussion might have been broader but that isn't even public so I don't think it should count.

In my opinion, it is not deceitful, as this PR intends to remove the incentive for creating new forks and distributions by removing publicity for any of them (no one will be led to believe that creating one is so encouraged it will be listed on that page). (That was also all what we discussed in the meeting, there was no one who wanted "to be in control".)

Sorry but this just continues to illustrate the issue, you were in the meeting so it's not deceitful to you, for the rest of us it is especially as there is a document actually inviting forks over in the main repository. Things like very delayed meeting notes, partial meeting notes and secret grant proposals illustrates how OpenRefine has been moving away from openness, even if no one might have the intent to take control.

The OpenRefine.org distribution has many short comings as @wetneb has illustrated and that's even more a reason why this list is important. We know that the feature-set of these distributions inspire people, we know that a lot of people wishes to see some of the features in the OpenRefine.org distribution, we know that people fork OpenRefine for various valid reasons. The discoverability of these distributions are important to the health of the project not something that harms it.

Note that I'm in favor of removing the invitation to fork OpenRefine over at the main repository.

[tfmorris]

It feels like this has become a proxy for a bigger discussion rather than about the PR itself. From my point of view, the list serves two purposes:

1. Highlight the popularity of OpenRefine by showcasing projects which have adopted it as a base
2. Provide marketing & promotional benefit to those projects which are aligned with OpenRefine's goals & values

When the packages haven't been updated for 8-11 years, I question whether the list shows OpenRefine in a good light for goal 1 and clearly defunct projects aren't in need of promotional benefit for goal 2.

Having said that, I'm happy to keep some version of the list around in a similar vein to the way we have a "legacy extensions" list.

The current division seems a little awkward with extensions, "legacy" extensions, and client libraries on one page and distributions (or whatever we want to call them) on a separate page -- and yet another page called "ecosystem."

I'm willing to volunteer to draft a more comprehensive update for folks to comment on which attempts to put more context around the various lists.

[Abbe98]

The current division seems a little awkward with extensions, "legacy" extensions, and client libraries on one page and distributions (or whatever we want to call them) on a separate page -- and yet another page called "ecosystem."

I'm willing to volunteer to draft a more comprehensive update for folks to comment on which attempts to put more context around the various lists.

This sound like a good idea! I could imagine a more "actionable" ecosystem page holding most of the information and lists which are now spread on various pages.

[magdmartin]

@Abbe98 thank you for clarifying your point regarding discoverability of distribution. As @tfmorris pointed out, since those distributions are outdated, they provide little benefit to end users. They may be interesting from an engineering (how did they solve one problem) and product management/roadmap (what people are ready to invest time in developing) perspective. For those reasons, they don't need to be prominently listed in our footer on a dedicated page. I drafted an ecosystem map last spring, which received feedback regarding its readability. The discussion is available in #325. I haven't had the time to revisit it to find a better way to present the information. It may be a good place to list them.

Regarding transparency, the entire discussion regarding this change is available either via the minutes or consecutive comments on the forum or this PR. Over the last 12 months, I have worked to increase the transparency of the organization with new pages on the website, published meeting minutes, and grant applications (successful and unsuccessful). There is room for improvement, and we are taking contributor feedback into account. Based on that feedback, we are now listing on the forum our intent to apply for grants (see the OTF Fund, Arcadia Grant conversations). Following the Barcamp, we also open the idea of creating goal posts to better present what we intent to work on and pool resources (volunteer, partner or funding). Separetly, three people requested today to have meeting minutes shared faster (here, here, and during today's Advisory Committee call). We will change our processes to release minutes the same day. I plan to continue improving the organization's transparency as outlined here.

@tfmorris, regarding OntoTxt, I suggest treating this point separately from this PR.

[Abbe98]

@Abbe98 thank you for clarifying your point regarding discoverability of distribution. As @tfmorris pointed out, since those distributions are outdated, they provide little benefit to end users. They may be interesting from an engineering (how did they solve one problem) and product management/roadmap (what people are ready to invest time in developing) perspective. For those reasons, they don't need to be prominently listed in our footer on a dedicated page.

Not all of them are outdated and even if all of them were it doesn't matter in the context of my arguments. Most feature requests are from end users, and even if that wasn't the case openrefine.org is not only for end users.

Regarding transparency, the entire discussion regarding this change is available either via the minutes or consecutive comments on the forum or this PR.

If so this pull request is still unrelated as it's not about removing the invitation to fork, now from @Ainali I get the impression that the discussion in the meeting extended to include the removal of this list as well but that's not in the minutes, and again illustrates what a harm these meetings do to the project.

Maybe it would be better if the AC wouldn't try to make changes to documentation, apply for technical grants, etc and instead stick to its responsibilities at outlined in GOVERNANCE.md:

The Advisory Committee runs the administrative aspect of the project on a day to day basis with the support of Code for Science and Society (CS&S).

[thadguidry]

I have to admit with @Abbe98 's last point, that even I am questioning what can/cannot the Advisory Committee do. Maybe their role should be to only advise maintainers, community/project leaders of the project? Then it's up to the maintainers, community/project leaders how they want to organize things and prioritize things?

I wish now for the old days when we had a very good form of simple meritocracy.

In this case, the Project Leader (currently @magdmartin) who makes the ultimate decision on this issue is called out in Governance , and not the Advisory Council (an existing board that really should advise only) which he is also a part of, but his primary role is that of Project Manager (I also don't like that term, as @wetneb as agreed with before disliking also).

Advisory Committee members

• Provide guidance and oversight of the Project’s staff and operations;
  ...
• Can be part of the Admin team for the project on GitHub

But just because we have that last bullet in our current Governance, doesn't mean that anyone on the Advisory Committee has the ultimate decision or assumes the Project Leader role.
The current Project Leader (Manager) role is @magdmartin currently as shown in the current Governance docs. That person currently has the ability to make any ultimate decision on the projects health, website changes, or this issue, which of course requires community input as we're doing now.

Regardless of current responsibilities that are clearly defined in our Governance currently, I also don't have a problem seeing forks or distributions of OpenRefine, an open source project, and in the spirit of open source, its perfectly acceptable to have them.

What I don't want to see happen is OpenRefine's, this project, advertise or encourage other distributions that do not contribute back to OpenRefine's ecosystem. Those kinds of projects kill our ecosystem, and do not help our community thrive. Let those kinds of projects/distributions handle their own advertising and community building on their own please, or within our forums, just not our website. So I disagree with @Abbe98 on his point of "The discoverability of these distributions are important to the health of the project not something that harms it."

[thadguidry]

@magdmartin This looks good to me.

[Ainali]

but that's not in the minutes

From the minutes: "we should stop explicitly inviting people to fork OpenRefine."

And that is the whole point, and in line with what Thad said, the very existence of the list is an invitation and encouragement.

I recognize that this conversation is deviating quite a lot, and probably should be in a more visible place like the forum because if "make changes to documentation, apply for technical grants, etc" is not supposed to be included in "the administrative aspect of the project" I would very much like the community to come up with a well-defined list of activities and responsibilities that the Advisory Committee should have/do so that we are focusing on the right things and have the appropriate expertise in it.

[Abbe98]

I think @tfmorris suggestion is a much better one.

[Abbe98]

but that's not in the minutes

From the minutes: "we should stop explicitly inviting people to fork OpenRefine."

And that is the whole point, and in line with what Thad said, the very existence of the list is an invitation and encouragement.

But it's confusing because we had an explicite invitation in the main repository. Again this illustrates how problematic these meetings are, as community members and contributors never could have know the scope of the discussion.

[Ainali]

But it's confusing because we had an explicite invitation in the main repository. Again this illustrates how problematic these meetings are.

I agree that it was confusing for a few days. However, I think it more illustrates the complexity of keeping multiple repositories in sync. In a perfect world, both PRs would have been made at almost the same time, referring to each other and the minutes, to show the entire scope of the change and intention. Clearly, that failed, but it is not the fault of the meetings.

EDIT: Looking closer at the PR you linked to, it was made only minutes apart from this one, referring to the same issue, so while I understand you feel confused, I am not sure how more explicit it could have been.

[thadguidry]

@Abbe98 that's not correct and maybe your mixing "extensions" with "distributions", maybe not? In that #6725 in the project's repo, looks like we only asked for authors of "extensions" to make PR's and edit the download page on the website...

If you want to list your extension on the download page, please edit this file.

and we removed the rest of the "distributions" part. Which makes sense to me.

I think this PR #357 is fine as is. And I look forward to reviewing @tfmorris further changes and welcome @Abbe98 and anyone else to help review. OpenRefine is ALL OF US.

[Abbe98]

But it's confusing because we had OpenRefine/OpenRefine#6725. Again this illustrates how problematic these meetings are.

I agree that it was confusing for a few days. However, I think it more illustrates the complexity of keeping multiple repositories in sync. In a perfect world, both PRs would have been made at almost the same time, referring to each other and the minutes, to show the entire scope of the change and intention. Clearly, that failed, but it is not the fault of the meetings.

In a open project the initial discussion would have happened in the open among contributors and community members instead of behind closed doors.

[Abbe98]

@Abbe98 that's not correct and maybe your mixing "extensions" with "distributions", maybe not? In that #6725 in the project's repo, looks like we only asked for authors of "extensions" to make PR's and edit the download page on the website...

No I'm not mixing "extensions" with "distributions", I even linked to the change above.

[thadguidry]

@Abbe98 Don't worry so much about the Advisory Committee... they can only advise us. We as a community make the ultimate decision on the project and its website (also in the last line of the Governance, it states that CS&S only manages the domain... NOT the website, that is all of our responsiblity and with @magdmartin having oversight if there's ever a roadblock on decisions on the website changes. OpenRefine IS ALL OF US.

[ej2432]

Hello, everyone. New Advisory Board member hopping in here. Forgive my ignorance. It sounds like there is not resolution on removing this language. What's the path forward to build consensus? A forum post? Or is there now consensus?

Regarding the tangents about the roles of the Advisory Committee and the Project Manager, I suggest that these conversations also be brought to the Forum for open, transparent, and accessible discussion. I am happy to share my thoughts about the roles of these groups within a venue that is more accessible to a greater number of our community members.

[magdmartin]

I conversation resumed on the forum under the July 25th, 2024, Advisory Committee only minutes.

I moved the initial conversation to a separate thread: Improving Transparency: Advisory Committee's Role and Community Involvement to increase visibility within the community.

I will respond to this new post on the forum. As for this PR, it is awaiting @tfmorris's proposed changes.