Discuss resurrecting or replace Dreditor to make d.o experimental improvements

The drupalorg queue has a few of these issues already.

I was thought this issue was a duplicate, but I can't find an equivalent one.

I'll just put one note here, since I cannot find an open issue about it:

For patch reviews, rather than duplicating what dreditor does, it would be great if we had a better solution. For instance, something like: https://www.reviewboard.org/ (which is an open source project, and allows people to actually review code changes in a meaningful way).

RE #4, if I can channel what @drumm meant in #2, I think he was willing for this to be the Plan/Meta issue, and we should find/add related existing issues (which might already exist in this project, or others?) and then create issues as needed for things that don't already have issues.

As such... Linking the issue that @drumm added to the summary in #2 as Related. And adding #3 to issue summary.

Given the DA specific strategy not to invest in any contributor level improvements, I doubt this will have any traction. It's clear that outside of the D.O domain we are more able to innovate and change this critical tool.

It's clear that outside of the D.O domain we are more able to innovate and change this critical tool.

Dreditor is going to be "decommissioned" soon due to the lack of availability necessary to fix the Firefox issue, which requires a complete rewrite of the code.

The fact of the matter is that d.o has a better chance of integrating minor key "features" (not review) more quickly than it would take to completely rewrite the code base of Dreditor.

IMO, if d.o integrated everything aside from review, that would be a great step forward.

That may allow us to "save" Dreditor (temporarily) as it would be a little easier to update the codebase, at least until d.o could implement a proper "review" solution (as mentioned above).

Yes, there are existing issues for many of the features at https://www.drupal.org/project/issues/drupalorg?text=dreditor&status=Ope...

Dreditor is going to be "decommissioned" soon

Is there any specific time for this?

I wasn't planning on removing any published extensions, so users should still be able to keep it if they have it installed.

It doesn't necessarily affect existing users per se; there just won't be anymore updates to it.

So if d.o changes, it will simply "remain broken".

I also planned on taking down the website sometime in the next couple weeks, maybe sooner.

I can start redirecting people/github issues here to this issue.

I have closed all GH issues and updated https://dreditor.org with a message that points back to this issue on d.o.

Hello @markcarver,
this is Val from the core mentoring initiative.
First of all, thank you for your continuous support and passion, I, among many others, is a big dreditor fan.
I see that there is a meta issue on d.o. to move all dreditor features to d.o. itself. This is a great thing when (if) it happens. Unfortunately, I don't see it happen before DrupalCon Dublin (correct me if I'm wrong).
Dreditor was (and is) an important tool that we recommend to the new contributors as part of mentored sprints, so I wonder if there is a chance to prolong the site's life until the end of September 2016. If there are any issues with the hosting, I can offer a VM at Hetzner for this period (or longer).
Just in case, for FF lovers who want the extension, trick to allow the installation is easy:
1. Go to `about:config`
2. Set `xpinstall.signatures.required` to `false`
Hope this can help someone

Best regards,
Valery

@valthebald,

Simply put: no, we will not "keep it alive" just for DC Dublin.

The decision to decommission Dreditor was officially made back in DC NOLA (May 2016) between the two active maintainers of Dreditor: @Cottser and myself.

This decision, however, started way before even that. It's just taken some time to consolidate everything and get it to this point.

I have been keeping Dreditor "alive" for almost three years now; ever since @sun essentially left the community.

There will always be some event or reason used to justify why Dreditor should live on.

However I firmly believe it is very important that we, as a community, move on.

---

@joelpittet is correct, the primary issue that "spurred" this decision into action was around Firefox: the inability to use the extension at all. He is also correct in that the "fix" you mention does not work in newer releases.

Also, before anyone says "I will help fix it", please keep in mind that https://github.com/unicorn-fail/dreditor/issues/256 has existed well over a year now, along with some other issues for an even longer period. This isn't a matter of "simple fixes".

It's a very complicated issue that would require a complete rewrite of all source code (as it would have to work in all browsers, not just FF). There had been a lot of people around to say "it doesn't work in FF", but only one individual that actually stepped up to the plate and attempted to "fix" it. It was a gallant start, but really just the tip of the proverbial iceberg.

---

In fact, d.o has been spitting out new features/changes left and right; in a much faster deliverable timeframe than Dreditor (thank you @drumm and the rest of the DA team!).

I think people are forgetting why Dreditor was originally created: to prototype new features for d.o due to it's stagnation. The development/deployment of "new features" on d.o was, historically, very difficult; in large part due to d.o running D6.

Ever since the migration to D7, d.o can no longer been labeled as "stagnant". In fact, I would argue that Dreditor now has that label. It is Dreditor that has to keep up with d.o, not the other way around anymore.

Dreditor was never meant to be self-sustaining or authoritative with its features. I unfortunately semi-changed this mentality when I created "native" extensions for Dreditor. The primary purpose of which was solely around easier installation and deployment of updates. That does not change the fact that Dreditor, at its core, is still modification code for d.o itself. Code that should, in one way or another, ultimately find its way back "home".

An example: #2340363: Add issue comment attribution

Dreditor was the original source for "committer attribution". After long and lengthy discussions (in a multitude of issues), d.o finally adopted the "idea" of this Dreditor feature. It's final end product, however, resembles nothing like what Dreditor originally implemented. That's fine, d.o had to accommodate a multitude of requirements.

---

The reason the site was taken down was not due to a lack of or difficulty hosting it. It was to prevent future installations and to notify people that Dreditor is being decommissioned.

As I have said before, if you already have Dreditor installed (Chrome/Safari), then it should continue working. That is until it, inevitably, breaks due to d.o markup changes.

---

I will not "hand over Dreditor's reigns" to continue keeping it alive either.

My mind will not change nor be persuaded.

For the good of the community and d.o.

Dreditor must cease to exist.

This decision is final.

In the meantime we can just tell sprinters at DC Dublin to install chrome and dreditor there.

Now we need someone to fork the dreditor github repository and ideally put up a dreditor-new.org site. Any takers?

Anyone that does, please rename it from dreditor to "Drupal.org Enhancements", might as well increase discoverability.

Alternatively we have a month to rebuild some of changes on the site.

FWIW it works in Firefox nightly where xpinstall.signatures.required is still supported. (Support for it in beta and stable was dropped, but not nightly).

As a bonus you get to preview new FF features and help test their newest builds.

I saw @klausi's tweet https://twitter.com/_klausi_/status/766028808243843073 this morning, lets not stop the development of Dreditor so quickly. I am sure there are many people who would like to maintain it - for the sake of learning, or as contribution to Open Source.

I would like to become the maintainer of Dreditor for Chrome. I think in future other people would be willing to help fix the issues for Firefox.

About my JavaScript skills - I'm learning JavaScript since last year, you can view my JavaScript repos here https://github.com/subhojit777/js-projects.

@klausi mentioned that we can fork the repo, and I was not able to find any open issues here https://github.com/unicorn-fail/dreditor/issues. Let me know what are the existing issues for Chrome and how I can help.

I think its totally fine that the current dreditor maintainers decided to stop working on dreditor. It is a good thing to move on from stuff you don't care about anymore or is too much work or whatever other reason you have. It is good. This is so good that we even have a code of conduct guidance for stepping down considerately: https://www.drupal.org/dcoc#stepping-down quoting in full:

Members of every project come and go and Drupal is no different. When somebody leaves or disengages from the project, in whole or in part, we ask that they do so in a way that minimizes disruption to the project. This means they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off.

Quoting for comparison the dreditor website:

Dreditor is being decommissioned due to the lack of availability of current maintainers and the fact that Drupal.org is becoming more feature rich at a much faster rate than Dreditor itself now.

(Emphasis mine). While I agree drupal.org should have the features, I don't think blackmailing the community to implement them ASAP (and making the drupal.org team hostage of the decision so they need to stop making changes to keep the current dreditor working until such changes happen) is considerately stepping down. Dreditor being an open source project, I don't see how its considerate to equate its existence with the availability of its current maintainers. I don't think that is stepping down considerately either, especially in light of:

I will not "hand over Dreditor's reigns" to continue keeping it alive either.
My mind will not change nor be persuaded.
For the good of the community and d.o.
Dreditor must cease to exist.
This decision is final.

(Quoted from above). It is much easier to do a backdreditor than a backdrop.

In defense of the current maintainers of dreditor I want to emphasize that the recent announcement may come out of the blue but in fact is the result of a long - often unrecognized - painful process. This is just my impression from following what's going on and I somehow expected that to happen rather sooner than later. They have asked for help for a long time, they have explained the problems for a long time as well. We probably should not underestimate the required effort to solve those problems now - they haven't been solved for months if not years.

The drastic action taken now was probably the last remaining path to create awareness. And if that was the intention, they succeeded.

To focus on the positive side of things, this whole discussion shows clearly the value of dreditor - so that's worth a big thank you to its maintainers for years.

Having said that, rather than trying to keep the situation as is, we may better try to find the best way forward regarding long term benefits. Re-building or further maintaining dreditor most likely leads into the same mess that the existing project wasn't able to overcome. Why should the community succeed next time? What's different?

Looks like quite a lot of people are around that are interested to help and all the arguments why all the features should become part of drupal.org natively seem to make so much sense, shouldn't we push for that approach and get that done? Not sure how the DA would utilize new contributors for this, but it's worth asking, isn't it?

I think @markcarver has made it clear that he does not want to hand over dreditor, so there is no point arguing about that. Let's just fork it and be done with it.

@subhojit777: Thanks for stepping up! Next steps:

* Fork the Github repository
* Restore README contents on how to install dreditor at least on Chrome.
* Restore old dreditor.org site, maybe on Github pages? it does not have to be its own domain, dreditor.githubpages.com or similar would be enough.

Please announce it here once you are done so that we know about it then :)

After discussing with Gábor I think keeping dreditor (fork) available is good.

But I do think that we should find the way ASAP to to move its features into d.o! And this is the goal of this issue (without "ASAP" :)), can you remeber? ;)

There is also fork by https://twitter.com/alwaysworking/status/766156440373370880 created yesterday.

So, there are a number of things that come out of this and in need of action. Some urgent, some are important but not as urgent.

Not sure if this is *entirely* correct, but something like this?

Now…

1. Fork Dreditor to provide the same functionality as we had
2. Ensure that all materials referencing Dreditor point to the *same* fork
3. Train mentors at DrupalCon Dublin on the agreed fork

Then…

1. Create a plan for improving the contributor experience of submitting enhancements to d.o
2. Incorporate dreditor-inspired enhancements into d.o

I am very happy to ensure that the mentor awareness at DrupalCon is consistent etc. We can ensure all the materials there are changed to reflect an agreed fork.

I’m also really quite keen to get involved in looking at the contributor experience to d.o - I’ve wanted to do this for a while and maybe this is the nudge I need.

All this rather depends on us getting that agreed fork, though.

I have forked the repo. I would like to know, whether we are going to use this same repo https://github.com/unicorn-fail/dreditor for future development? Or do we create a new one.

@subhojit777: @markcarver and @cottser indicated that their decision to neither continue nor hand over that project/repo is final, so no.

klausi, Gábor Hojtsy, and subhojit777

I've created the fork, https://github.com/mattgrill/dreditor. I'm not going to have much time this week + weekend to have a look around. Starting next week (8/22) I can bring some things back, restore the readme, and hopefully come up with a plan to make development a little smoother.

I will have time this weekend. Lets finalize the main repo for Dreditor. I would suggest that - lets create a new organization for this say, dreditor. And the dreditor repo will be under the "dreditor" organization (dreditor/dreditor).

As an aside regarding the Firefox problems: Dreditor started out as a Greasemonkey script. It's only about a couple of years ago that it was converted to a Firefox extension. I've not dug very deep into the reasons for this, but might reverting to using Greasemonkey be one way to continue supporting Firefox?

@joachim Looks good. It would be good, if we bring back the Dreditor page back at first, and make the extension available for Chrome. Then we can plan to make it available for Firefox. One of the maintainers can solely work on the Firefox support, and the other will support the Chrome issues.

Suggestions please.

This project is only indirectly connected with mentoring, yet I think it would be a good idea to have the namespace of https://github.com/drupal-mentoring. What do you think?

Something more to do with 'drupal.org tools' might be better?

(Veering off-topic here, but I could move https://github.com/joachim-n/dorgpatch into it.)

New organization created - https://github.com/dreditor
Main Dreditor project repo - https://github.com/dreditor/dreditor
Home page - https://dreditor.github.io
Project page repo - https://github.com/dreditor/dreditor.github.io

@drpal I have added you as a collaborator, and you have the admin access.

Remaining tasks:
- I am going to look how I can add the releases link in the project home page.
- Add TravisCI integration. (https://travis-ci.org/dreditor/dreditor)
- Add badges with correct URLs in README

I was referring https://github.com/unicorn-fail/dreditor/blob/1.x/RELEASE.md, there it says how we can update the Chrome extension. I was going to do that then I found it is asking for $5.00 to create an application. How we are going to do this. I guess Mark Carver is not going to handover the previous account, in that case we have to purchase a new license.

For the record, I'm not "blackmailing" the community. I made a calculated and rational decision about a project I am well knowledgeable in and no, it wouldn't be "much easier to do a backdreditor than a backdrop" given the current state of code.

Instead of wasting everyone's time, I decided that decommissioning a severely broken and antiquated tool was more appropriate than giving false hope when there is none.

Furthermore, it's a tool that, by the "community's" own admission, is "officially unsupported" and has indeed been broken several times due to d.o "changes".

I have tried to bring light to a multitude of issues over the years both on d.o on GH, but no one seems to want to listen to what I have to say. That isn't my fault.

If it's truly as "widely needed" as people are making it out to be here (which it's really not), then it should be "officially" supported (which it isn't and shouldn't be now, don't say that it should be... that ship has sailed, don't egg it on please).

If anything, I would argue that it's the community that has been "blackmailing" d.o by insisting to continue using this tool instead of focusing on integrating the features natively on d.o.

The whole point of this project was, and is, that it would eventually be superseded by improvements made on d.o directly. This has always been the plan, regardless of what people may want to believe. This process has simply been expedited by the facts mentioned above (again, if anyone cared enough to read).

Re: core mentoring

Yes, there was some prototyped features per the request of @YesCT and @Cottser (issue cloning/issue summary templating), both of which could easily be "fixed" on d.o.
And yes, it was easier to on-board new people via a one-click install process because I turned the original content script into native browser "extensions".

However, Dreditor was never a core mentoring tool. Period. Nor has core mentoring owned or dictated the direction of Dreditor. It asked for features, we provided them, as a prototype. Funnily enough though, these prototypes end up not going anywhere. They just sit there, in Dreditor. It's not Dreditor's fault that they haven't been moved into d.o by the core mentoring team.

Re: #41
Please take it down. This was premature. I haven't read the comments since only 4 days ago to reconsider the DC Dublin extension.

---

Since no one can read apparently and insist on hi-jacking this issue and beating the dead horse alive, I'm now being forced to accommodate the shrillness and disrespectful tone of this issue.

When I said the maintainers don't have availability, it was in direct reference to a complete overhaul of the code it would require.

It does not imply that I am "leaving the community", that I "don't care about the project" or that I'm "stepping down from this project" (which is why I'm not "giving up the reigns").

The project itself has reached EOL. Period.

It's successor, d.o, is very much alive and well.

I have not "violated" any DoC, unlike several people in this issue already.

Despite the fact that I have repeatedly mentioned that your currently installed versions will still "work", that too is apparently "not good enough".

Instructing new people to use an antiquated tool that is and SHOULD go away is counter-productive to the overall purpose behind said project. If we continue to try and "keep this alive", we'll never make progress where it really matters: d.o itself.

Sigh... whatever....

I've reinstated https://dreditor.org (with great reluctance) so it can still be "installable" for DC Dublin. Keep in mind, it will only work with Chrome (maybe Safari too, I haven't tested in a while).

After DC Dublin, Dreditor will be no more.

+1 for not putting further effort into dreditor and instead focusing on replicating its UX improvements on d.o.

Ok. Fine. Seeing how you're making this a Dreditor specific issue and not a d.o issue, and the fact this project is simply at EOL, I'm closing it as the maintainer of that project.

You're the maintainer of https://github.com/unicorn-fail/dreditor.
@subhojit777 and @drpal are the maintainers of https://github.com/dreditor/dreditor, which is now what we're discussing.
Good luck in your other issue.

There's nothing to discuss. It's already been forked. You are all making this into something more than it really is.

Anybody can fork anything, that isn't what this issue is or was ever about. If they want to continue going down a doomed path, then that's certainly their prerogative. Good luck to them. They'll certainly need it considering how the community respects those who "resurrect" dead projects (see you in 3 years making the same arguments).

What I find utterly bewildering is why no one seems to be able to read and continuing to reopen a non-starter issue.

@markcarver: please stop closing this issue, since people are working on it.

When for example your computer gets old and it is probably time to replace it, do you throw it out of the window immediately and then start looking for a new computer? Of course not! You keep it until you have chosen a new computer and it has arrived and you have move your data over to it. Only then you decommission your old computer.

And we are going to do the same thing with dreditor, please stop holding us back.

Actually this issue makes me so furious I could take random things from my desk and smash them out of anger. Instead, I'm going to channel that energy into cheering for the new maintainers: go @subhojit777 and @drpal!

+1 to what @klausi said

@subhojit777 and @drpal: where do you hang out to discuss the project? I'd like to dive in

@drpal @valthebald We can discuss on IRC. Let me know if that works.

@subhojit777 - keep me in that IRC loop, too, please. For Dublin duties…

Rachel

@rachel_norfolk If we are going to use Dreditor in Dublin, the first step would be to purchase a license for Chrome apps (or we can use the old one?) Workaround for purchasing license would be, use the plugin in developer mode https://github.com/unicorn-fail/dreditor/blob/1.x/CONTRIBUTING.md#chrome. People can do to the Dreditor project page https://dreditor.github.io, they can download and use it by enabling the developer mode. Of course that would become a bit cumbersome.

@markcarver:

I've reinstated https://dreditor.org (with great reluctance) so it can still be "installable" for DC Dublin. Keep in mind, it will only work with Chrome (maybe Safari too, I haven't tested in a while).

After DC Dublin, Dreditor will be no more.

What's the value in that? I imagine mentors teaching "here is a tool we teach you but tomorrow you'll not be able to install it anymore on your other computer or in your other browser". Sounds very practical? Would you spend time learning such a tool? If mentors are to teach a tool that would be something that has a chance of at least being able to access/install/read docs, etc. other than on the magic day of the sprint. Otherwise mentors are doing a disservice to the attendees. (It is of course not a problem later on if the given tool goes obsolete because its features get directly integrated on drupal.org before it stops working / not installable anymore).

This issue title (now, after its blatant hi-jacking) is "Discuss resurrecting or replace Dreditor to make d.o experimental improvements".

Seeing how some misguided people have already forked it, there's nothing to "discuss" anymore. They didn't listen to the reason and logic I laid forth. They didn't respect the "community" or the "processes for taking over an existing project" (like I did nearly 3 years ago BTW). They assumed that because I was declaring EOL that I was "stepping down", which isn't the case.

I'm still the primary maintainer of the "Dreditor" extension. The "fork" in this case wasn't to diverge code; it was to subvert the "official" project because they "disagreed" with our decision and attempt to MOVE FORWARD on d.o itself. They want to remain tied to a "browser extension" that requires manual installation and something that doesn't exist for mobile experience.

God forbid we actually attempt to fix d.o itself...

When for example your computer gets old and it is probably time to replace it, do you throw it out of the window immediately and then start looking for a new computer? Of course not! You keep it until you have chosen a new computer and it has arrived and you have move your data over to it. Only then you decommission your old computer.

Your analogy is flawed. The decision to decommission Dreditor didn't affect existing installs. Your currently installed local browser plugin will still work, as I have said several times now.

I did not "throw it out the window". I "put it on a shelf, still plugged in" and it's still [currently] working more or less. I also let people know that is what I did. However, for some reason, you and several others want to keep making this into something it's NOT.

There's no respect. That is what makes me angry about this issue. You think I just woke up one day and decided this? This has been inevitable since the day I took over nearly 3 years ago. I too essentially revived Dreditor then since @sun actually left. This, however, is not the same scenario. Things have drastically changed, primarily on d.o.

please stop closing this issue, since people are working on it

Please stop re-opening this issue. If anyone wants to continue being disrespectful and continue working on their own "fork" then they can do so in their fork's issue queue, https://github.com/dreditor/dreditor/issues in this case.

Your analogy is flawed. The decision to decommission Dreditor didn't affect existing installs. Your currently installed local browser plugin will still work, as I have said several times now.

Mark you are both claiming Drupal.org is now changing fast and that Dreditor will work until Drupal.org changes in an incompatible way, so its fine. Do you understand what these two put together mean?

Those two put together can easily mean Drupal.org changes in an incompatible way much sooner than Dreditor features are ported to Drupal.org. The extent to how the community is dependent on the patch review functionality among others, that would be a devastating loss. In this case you are blackmailing the users to implement such d.o features before D.o changes in an incompatible way and they ultimately loose functionality otherwise.

The other scenario is that Drupal.org team's hands are tied to not make such incompatible changes, so Dreditor keeps working which slows down other innovations on drupal.org. In this case you are blackmailing the Drupal.org team to implement the features you think are highest priority in a time where they fired people to reduce costs and trying to focus on changes that make money so the rest don't need to be fired.

Finally you are blackmailing the group of people who did not have dreditor installed yet to implement the d.o features you think are highest priority, because they have bad luck having no way to install it and be part of the exclusive club who can use Dreditor features until its ported to Drupal.org.

With all due respect to your work you done earlier on the project, trying to force the hands of at least three groups of people now is not responsible open source maintainership in my book and cannot be respected.

I don't think anybody wants to not have the features on drupal.org as soon as possible. Doing it this way is not fair.

Do you understand what these two put together mean?

Yes. I'm well aware what these two together mean. I have lived through the D7 upgrade which completely broke Dreditor... remember?

The "change" (in respect to breaking Dreditor) aspect of d.o has slowed over the past year. Yes, there are still a few tid bits here and there, but the majority of Dreditor's functionality has remained mostly intact.

What I meant by "d.o being faster", is it's ability to implement new features. So far, this has had little impact on Dreditor.

In this case you are blackmailing the users to implement such d.o features before D.o changes in an incompatible way and they ultimately loose functionality otherwise.

This is highly unlikely to happen anytime soon. Dreditor has remained relatively untouched for almost a year now aside from minor tweaks to annoying bugs. The patch review plugin itself hasn't seen any significant work in almost two years.

In this case you are blackmailing the Drupal.org team to implement the features you think are highest priority in a time where they fired people to reduce costs and trying to focus on changes that make money so the rest don't need to be fired.

The d.o team could (and does) receive help from community members. While they maintain the code, it doesn't prevent the community from moving forward in helping implementing said features. If we stopped bickering about "omg dreditor is dying" and stop wasting precious time by trying to "keep it alive", then we could implement said features FOR the d.o team.

Finally you are blackmailing the group of people who did not have dreditor installed yet to implement the d.o features you think are highest priority, because they have bad luck having no way to install it and be part of the exclusive club who can use Dreditor features until its ported to Drupal.org.

Saying that new users are being "left out" of the "exclusive club" is a real stretch. This project is an enhancement. It does not prevent anyone from not doing their job or contributing. In fact, I know people who hate Dreditor and don't use it. You're making Dreditor a "requirement" for those who don't even know it exists. Regardless, that is why I turned the site back on, so... if they want to install it, they can.

With all due respect to your work you done earlier on the project, trying to force the hands of at least three groups of people now is not responsible open source maintainership in my book and cannot be respected.

@Gábor Hojtsy I'm not "forcing" or "blackmailing" anyone. Please stop saying that I am.

Doing it this way is not fair.

Neither is complaining about losing something no one was willing to help fix.

---

In retrospect, I perhaps could have worded "decommissioning" a little bit better. People have assumed that by taking this action that Dreditor will "suddenly be gone". That is false. It's open source, it will always "live on" in that respect (as evidence by the fork). This was more about a mentality shift and getting people to recognize that the cost effectiveness effort it will take to sustain something like Dreditor is not worth it in the long run (given that d.o features are more easily implemented now).

Furthermore, I think the primary "mistake" on my part was not saying "when" Dreditor would be decommissioned. Taking the site down doesn't "decommission" it, the Chrome extension was still installable (just not from the site). This is also what I meant by "After DC Dublin, it [the site] will come down", not the Chrome extension.

I also think it needs further explanation that the "decommissioning" was more about not fixing FF, implementing NEW features into Dreditor or wasting time on small annoyances (like styling changes). While I had not planned on making anymore releases, the reality is that if something as major like the patch review process were to "break", I could see making an exception to quickly fix it until a d.o solution were in place.

So, with that in mind, I think putting a goal for when Dreditor should actually be decommissioned (actual EOL) should be sometime in the next year (hopefully by the end of this one).

That being said, and given that the https://dreditor.org infra is already in place (builds/packaging), it would make more sense to just add @drpal and @subhojit777 as temporary co-maintainers so they can tackle whatever they feel they need to. There's no point in wasting everyone's time (which ironically is what this issue has done).

I realize some may see this as me "changing my mind", but rest assured I have not. Dreditor must die. I was hoping people would just go "ah yeah, ok then that makes sense", but it appears that isn't the case and I have been personally attacked by people who have no idea the amount of infra that is required to help maintain something as complex as this project has become.

Since there are still many features in dreditor that are not yet implemented on drupal.org, yet still relied upon by many in the community (e.g. code reviews), dreditor does need to live on in some capacity. One option would be for the DA to make a small module that allows users to optionally configure whether or not they want the current dredditor javascript/css added to their drupal.org experience. (#1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features)

This would have a number of benefits: it would no longer be browser plugin dependent, it would enhance discovery of its featureset, and it would put control of conflicting features into the DA's hands (we've already had to delay releasing features in order to coordinate releases with dredditor maintainers, specifically ckeditor issue summary templates).

The main drawbacks are that it would mean that in order to prototype experimental features for drupal.org, developers would have to coordinate with DA staff and utilize our dev environments, vs submitting pull requests to dreditor. The other drawback is that DA staff resources are limited, and we wouldn't be able to prioritize any fixes to the existing code if needed, but like Mark has mentioned before, its pretty stable and hasn't seen much change in a long while.

@Mixologic! I did not know about that issue, but yes #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features makes the most sense considering that I do not plan on implementing any new features!

This would allow us to effectively "kill" the browser based extension while keeping its "features" intact. It would also introduce it to a larger base of users and even allow it to work on a mobile experience (but will likely need a bit of refactoring).

I'd even be willing to help maintain that code (as native d.o JS will be easier to work with) until its "features" are replaced by proper implementations.

This would also, effectively, fix the "FF issue".

Yes, yes, very great idea @Mixologic!!! :D

@markcarver: please stop closing this issue, since people are working on it. This is not your dreditor issue queue where you decide if we are allowed to discuss or not. Obviously there is a big need to coordinate the future of dreditor, so let's keep this open until we have figured it all out.

@klausi, as I have stated many, many, many, many times before.... nothing is being "discussed", a fork was made... that's it. No work has actually been done yet (aside from "setting up" the GH site).

You're making it sound like I'm not working (with others) to actually solve this issue. That could be further from the truth. In light of @Mixologic's comment above, #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features is the most logical, sensible approach and effective "solution" to this and many other issues facing Dreditor:

1. Essentially "saves" Dreditor
2. Will fix the "FF issue"
3. Allow mobile usage of Dreditor features (finally)
4. Allow users to toggle which features they want to use (finally)
5. Gives us and the d.o team the time that's needed to create replacement implementations of these "features" in a proper way (which, again, has always been the goal of Dreditor)

This is not your dreditor issue queue where you decide if we are allowed to discuss or not.

No, but this issue is about Dreditor. A project where I am the lead maintainer and still the lead expert on what is or is not capable of being accomplished with this project. You seem to keep forgetting that basic fact.

People also seem to be mistaking my closing this issue as some indication that I'm just saying "Oh well, tough luck, you have to live with no Dreditor". That isn't what I'm saying. It's never what I have been saying.

So, I'll try a different approach to the status of this issue then: "Closed (works as designed)": the browser based version of Dreditor is obsolete. It does exactly what it's supposed to do (as best as it can) and has served its purpose.

However, any browser based approach is not a viable "solution" moving forward:

1. Native browser extensions are extremely complex (given what we're attempting to do with Dreditor and dealing with multiple browsers)
2. Firefox has no real solution in sight without a complete overhaul of the code (which would take a massive amount of time/resources, things we lack)
3. Greasemonky isn't a viable alternative either, despite its Dreditor's origins because it still requires teaching new users how to use it. This is why Dreditor was moved to its own standalone browser extensions and why it became ever more popuplar, a.k.a. core mentoring tool.
4. Browser based solutions don't work in mobile
5. Browser based solutions of Dreditor will likely still be restricted to implementing an "all or none" approach of its features. Preventing users the ability to choose which feature(s) they want to actually enable.

#1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features is the right approach given everything that I have mentioned in this issue. This will allow us to "resurrect" (what this issue has turned into) Dreditor as well as give us time to implement the features properly later down the road.

This issue has been solved. Leave it be @klausi.

Oh, of course we are discussing: who can keep dreditor alive, where do we put the new homepage if you take the site down, where will the repo be, when will we change doc pages pointing to dreditor, etc.

I'm well aware of the technical limitations and problems of dreditor, but it is the only tool we have right now which is quickly accessible in the browser.

I'm all for the drupal.org changes, yes please! Usually they take a long time to implement, so in the meantime let's make dreditor great again.

On behalf of the Community Working Group this thread has been brought to our attention. Understanding this issue is particularly important to many people I would like to remind everyone of the Code of Conduct:

https://www.drupal.org/dcoc

In line with our conflict resolution policy, we hope as a first resort that disputes can be resolved through both sides reaching mutual compromise. The CWG meet weekly and will look further into this issue then but we hope in the meantime discussion will be considerate, respectful and collaborative.

From historical experience with the difficulty of getting changes on d.o, and the worsening financial restraints on the DA,
I think we need dreditor in a place where it can live outside of the DA.

Github is a good option, people can fork it to fix issues, when it breaks, that they really need.

Somewhat I agree to move the features to d.o. site itself, because it will be independent of any third party integrations. I don't know much about past experiences as @YesCT mentioned in #69.

Seeing how some misguided people have already forked it, there's nothing to "discuss" anymore.

I like this Dreditor tool very much, that's why I thought it shouldn't die so quickly just that d.o. features are moving too quickly, or Firefox is developing quickly. Dreditor saves lot of time and improves the UX of creating issues or adding comments. In my case few things like, opening and closing HTML tags, tagging people, etc. - this sometimes become cumbersome and irritating when done manually. Someone should maintain this nice project :)

Anyways, I have started watching the old Dreditor repo https://github.com/unicorn-fail/dreditor so that I will be notified to any new issues.

@markcarver Can you please update the GitHub link at https://dreditor.org so that it points to the new repo https://github.com/dreditor/dreditor.

From historical experience with the difficulty of getting changes on d.o,

I would point out that every time somebody brings up "historical difficulty of getting changes on d.o." they are talking about a *way* distant past that frankly is not true anymore. The processes have changed, and so have the requirements.

If you want to completely re-architect a feature of drupal.org, then yes, you're probably going to have a great deal of difficulty getting something like that over the finish line. If you want to make incremental changes, then that process is much simpler these days.

Mark has already requested a dev site, and began work on making this particular feature possible.

As I mentioned before, a very big complication that has always hampered us is not having ownership over a featureset considered 'essential' to the site, so this would be a win for us to not have to work around dreditor being something 'outside'.

@subhojit777: thanks for putting https://dreditor.github.io/ up!

Next steps:
* Copy infos from https://dreditor.org/ to https://dreditor.github.io/ , because dreditor.org could be shut down again at any moment.
* Provide beginner friendly getting started instructions on the Chrome browser. This could be something like:
* Install Google Chrome
* Disable security setting X
* Enable developer mode at place Y
* Download dreditor from Z
* Install the dreditor script at A

That should be enough to survive the mentor sprint at Drupalcon Dublin, right?

... a very big complication that has always hampered us is not having ownership over a featureset considered 'essential' to the site, so this would be a win for us to not have to work around dreditor being something 'outside'.

As a contributor who initiated and developed another 'outside featureset' that the DA later assumed ownership of, who was subsequently informed by the comment author that "Your assistance is no longer wanted, nor welcome on this project", and having witnessed very little progress on said initiative since ... I would suggest caution in assuming this would really be "a win".

Frankly put, the DA staff does not have the resources to both support and evolve their current accountabilities; and yet there are individual staffers who appear to be advocating for increased scope and control regarding community tools, while at the same time discouraging community participation and involvement in their development. Yes, having the dreditor functionality natively available on drupal.org would be a win ... but I really question how or whether not having 'ownership' has has actually hampered the DA.

The possibility of building these features into drupal.org has always been a possibility, and the dreditor maintainers have never interfered in that ... the only reason that drupal.org maintainers haven't done it yet (from a DA perspective) is resource shortages and competing priorities, not a lack of "control" or formal "ownership" of the Dreditor featureset by the DA.

(Edit: Changed 'ownership of Dreditor' to 'ownership of the Dreditor featureset')

Just a heads up.

I have added the Chrome extension link and manual installation instructions in the project page (https://dreditor.github.io). People during code sprint can either use the tool via extension or via manual installation. Let me know if this enough for the mentored sprints.

And, all the content from dreditor.org is brought in the new project page https://dreditor.github.io

In regards to @jthorson's comment above.

I get what you're saying, but that circumstance was very different from this one.

Yes, Dreditor remained a standalone project for many years. This was, in part, because d.o's upgrade was still so new. Adding something like Dreditor wasn't even remotely on the board of priorities.

However, things have changed. Drastically.

I still think there seems to be some confusion around why we decided to decommission the browser based version of Dreditor. The "inability to maintain" it has never had anything to do with the actual JS feature set code (the stuff in Drupal.behaviors). That stuff has been, relatively, easy to implement and maintain. It has always been about the direct correlation of effort/time and the infrastructure required to build, deploy and getting said JS feature set code to load on d.o properly via a browser extension.

FF has always had a very strict security review process for their extensions. This has, recently, been made quite clear by the fact that extensions must now be signed. For that to happen (easily), the extension must listed on addons.mozilla.org. We attempted to list there. Unfortunately they kicked back with a ton of "security concerns", regardless of the fact that the extension was regulated/loaded only on d.o sites.

Again, I'm not "stepping down", I was merely accepting/declaring that the medium in which we provide said features is antiquated and unmanageable. I was merely attempting to move the conversation of assuming that these will be "browser" based to instead a feature of d.o itself. Granted, I was originally assuming that these would be proper back-end (non-JS) implementations of said features... but that clearly isn't going to work.

Which is why #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features is the next important step forward. This isn't putting the "burden" on the DA staff. I'm doing the work and I will continue to do the work, as the "Dreditor" maintainer. If/when these enhancements become fully fledged standalone/baked-in "features" of d.o (likely more back-end related)... then that's when the responsibility will shift IMO. I could be mistaken.

I love Dreditor. I have always loved it, especially coding it. That isn't changing. What we call it and how it's implemented is. There's nothing wrong with that.