Disable the Github Sync user account: it's confusing

This is not a spam account and currently used by myself to automatically post patches when I push to github.

This account is used to experiment with Github's API and how we can leverage it to do Drupal core development more efficiently.

Please explain in more detail how this is spam.

-1

@klausi & Co came up with a creative idea for working on Drupal core patches via GitHub repositories. The idea and implementation is certainly not complete and done yet. Every new idea has to start somewhere.

The Github sync user account and functionality is limited to @klausi at this point.

But already in its premature state now, a proper patch is posted/attached for review, in order to follow our existing patch-based development workflow.

As a consequence, there's not much difference compared to me and everyone else posting a patch that is maintained in a Drupal core sandbox and generated via git diffup.

It's certainly in an experiment stage for now, so I don't see a point in blocking that user account.

As a compromise, perhaps @klausi is able to tweak the implementation to post d.o follow-ups under his own username?

Because if it wouldn't have happened under that separate account, I bet that absolutely no one would have noticed.

I see this is an attempt to reconcile the two camps - those who want to use github, and those who want to retain the patch-based workflow. I think it opens our doors to those contributors who are more familiar with github without disadvantaging those who are already used to our current workflow. i.e. I think this grows our community.
If comments on the reviews on github are posted back too, I don't see this as any different to any other patch/review tools ie git aliases/scripts in the case of patches and dreditor in the case of reviews, especially if the comments are posted in the name of the author.

What @larowlan said, I guess. The idea and experiment is a (different) attempt in the quest of seeking for a development workflow that encompasses both the Drupal core development workflow but also common git(hub) practices.

The idea here is not targeted towards black and white as #4 makes it appear. It is not an attempt to move git away from drupal.org in any way.

Dreditor could have been banned from d.o in its early stages on the same grounds. That did not happen. Instead, it advanced into a tool that is very helpful and powerful for core developers and power users of drupal.org.

Yes, I agree that posting in the users name is needed before this becomes anything more than an experiment.

This experiment should continue IMO. Folks can work on oAuth in order to help with the username issue.

The core issue is that drupal.org offers an outdated code review system that mostly depends on a client side browser extension. This has been the case for years and I commend anyone tries to move the needle toward progress. I think Github sync is a worthwhile attempt given what d.o. offers. Surely it can be expanded to add a username in the body and instructions about where to post issues. We don't need a nuke-it policy to achieve that.

Well, our opinions differ. Centralization of the community helped Drupal in its early years but it is currently holding Drupal back. This is obviously part of a larger discussion and I don't think this issue is the place to have it.

grumble.

sigh. the passion here is high.

When it gets that high, it makes people who might have wanted to add an opinion, go away. And since we are talking about not fragmenting the community specifically about the sync, it is worth pointing out fragmenting is happening *in this issue* because of the high passion level.

--
about the issue.

I'm interested in having some sample testing issues we use where multiple people could use the github sync and try it out.

Seems like having the posts I make using a tool like that, appear to come from *me*, my d.o account, would be a good thing.

Note that if there is no solution I will ban this user a week from now, then get on a plane to Hawaii and rest.

You do not have the right to make ultimatums and threats of banning. A ban comes as a result of community discussion. Please do not do that unilaterally.

The original post is full of subjective hyperbole. That is not conducive to a positive result. I tried to edit it to be less subjective and emotional. I removed this line " policy must ban alternative public issue queues and linking to third party issue queues." because suggesting that a website on the internet stop linking to other websites on the internet is...a bit unlikely.

I would prefer to keep the Github Sync account, because other people can also submit pull requests against my Github Drupal fork. It would be bad if those sync comments would then be routed through my personal user name.

Of course people can setup their own Github Sync server if they want to post through their own accounts, but I would like to keep the barrier to use this low.

That's the problem, right there.

So far you are the only person who has identified this as a problem, so you're going to have to do a better job explaining your perspective or adjust your attitude toward the situation.

@klausi, the proposed policy for how shared accounts can interact with drupal.org currently does not include posting comments. #1863498: Create Basis for ToS to allow organizations to share accounts. That issue is not in a "fixed" status but it does represent a fairly long discussion on the topic and it was suggested that a shared account should not post comments. IMO the Github Synch user should follow those ideas even if they are not in a finalized state.

This is pretty clearly a decision for the Technical Working Group, so moving to that queue.

And unfortunately, we probably now also need the Community Working Group involved, since chx has chosen to escalate his concerns in the manner he did.

For anyone new who's reading this thread, as a member of the CWG, I just want to point out that this is not in any way the way we are expected to (and typically do) treat each other in the community.

I'm not convinced the Github Sync account is comparable to an organization account. It is always clear in which name the account posts a comment (the author on Github is posted as part of the comment), so the account is merely a mediator.

So for the sake of having a meaningful Github pull request experiment I would ask the Technical Working Group to grant an exception for the Github Sync account so that other core developers can also easily take part in this experiment. If it shows any signs of going wrong we can still shut this down. I don't see big risks in trying this out.

I use github in my day job and it's one of the best tools out there, and pull requests are really well implemented. I've been previously been vocal about my dislike of the drupal.org issue queue. That's not a criticism of its authors, it's just that writing a good issue tracker is a huge task, and d.o doesn't have the resources of github, atlassian, mozilla.org etc.

But as long as drupal.org is our primary issue tracker, we need to make sure that it contains everything there is to know about an issue and is as easy to read as possible. That means we need to be very careful about encouraging discussion elsewhere that doesn't then make it to the issue (which can already be a problem with irc) or makes the drupal.org issue confusing.

Clearly making comments as "Github sync" is less than ideal, and breaks other features like auto-follow, reporting, user-specific filters people have set up on their bugmail, dreditor patch attribution etc, so we need to allow this to work under people's own user accounts before rolling it out further.

We should also be careful about having discussions on github, even if they do get synced back to drupal.org. Imagine Alice is working on a patch and Bob is reviewing it, both on github. What happens when Carol posts an important point on drupal.org? If it Alice and Bob aren't following the issue then they won't get an email notification, and it will get buried in the history as they continue to discuss the patch they were reviewing. Similarly, if Bob's review comments are synced to drupal.org, will they make sense without the context you see on github?

I think the only way this would work is if github is effectively read only other than for the commits themselves. Maybe that would mean the scripts would read the patch/code review, format it for drupal.org, post it on drupal.org then delete the github version. Even then, the reviewer has two workflows depending on the patch author's preference - one for patches uploaded to d.o, and one for pull requests. Will people end up feeling they have to use github if they want to get their patch reviewed?

https://groups.drupal.org/node/313218 the discussion on Phabricator is a bit related in that it might get us some of what the github sync is trying to do.

@webchick: can you clarify your comment?

This is pretty clearly a decision for the Technical Working Group, so moving to that queue.

There are several ideas/elements in the original issue and following comments so the sentence is a little unclear. What is the "this" in that sentence? Maybe an update to the issue summary would help.

Meanwhile, I experienced GitHub Sync follow-ups in some more issues. I still like the idea and want to support the experiment, but the proxy nature of comments, lacking proper attribution and content, is a bit concerning.

Especially in issue follow-up e-mail notifications, the auto-generated comment content is a bit perplexing and most often incomplete — it's hard to figure out who actually authored a new patch and the comments do not always state what has been changed, fixed, or improved.

Now, because we're all trying to collaborate and work with each other, and because the current behavior of this (great) tool happens to result in a degraded work environment experience for others, I don't think we need to look very far for an adequate policy, since there is a simple rule of thumb:

One person's freedom ends where another person's freedom begins.

In light of that, I'd like to quote myself from #3:

As a compromise, perhaps @klausi is able to tweak the implementation to post d.o follow-ups under his own username?

Because if it wouldn't have happened under that separate account, I bet that absolutely no one would have noticed.

As already mentioned in #6, that approach would also be in line with Dreditor's original and early history:

1. After reviewing hundreds of patches and manually copy/pasting code snippets, I secretly wrote myself a user script that allowed me to comment on the (raw) output of .patch files on any URL in my browser. No one knew. For months.

2. After experiencing an increase in my productivity, I advanced on the experiment to integrate more deeply into drupal.org HTML pages, to allow me to do more funky things. No one noticed.

3. I published the tool as a visible project on drupal.org. Many people started to use it. But their usage of Dreditor was still transparent/invisible for others. People who did not know of Dreditor were not aware that it even existed. Collaboration as usual. Some with Dreditor, some without.

4. Lastly - and perhaps the closest comparison to the situation here - to increase awareness, I made Dreditor automatically add a promotional "Powered by Dreditor" footer line to all patch reviews.

   → People rightfully started to complain that this is disturbing our collaborative work environment. In turn, that was removed, and everything was fine for everyone again.

In short:

As long as the goal of this experiment is to integrate with our existing environment on drupal.org, the path to success is to design the tool in a way that causes its usage to be invisible/transparent for everyone else — so as to not disrupt the workflows and experience of other contributors and prevent the tool from being a distraction from our actual goals:

Being productive together.

I don't think it's particularly controversial to say that, in its current form, Github Sync has problems.

On #829464: orderby() should verify direction [DONE] and escape fields:
- #36 doesn't include an interdiff and makes no indication about whether #35 has been addressed. There is a link to the pull request, but not to the specific commits that were made since #34.
- #37 shows that older files weren't being hidden. While hiding files is not required, it's a demonstration of how interacting via github can lead to a worse experience for people who are using drupal.org.
- #41 shows that it's incompatible with existing developer tools, in this case dreditor's commit message generator.

On #2184231: Use ConfigFactoryInterface to type hint ConfigFactory:
- #16 is an additional email that wouldn't have been sent with the traditional process.
- #17 is an example of someone wanting to test the functionality on a real issue and adding noise. The comment shown is a little messy, and it looks like Github sync just pastes the whole hunk in there - not a big problem in that example, but could be very noisy when commenting on a large hunk.

I think Github Sync has potential, but it's just not ready for use yet and the little use it has had is harming our issues. I'd like klausi to switch it to using his own account, turn it off for other users until it's more polished. If he isn't willing to do that, then I think we should suspend the Github Sync account.

I respectfully disagree. While it is not perfect I consider those problems relatively minor, far from harming our issue process.

So let's also add what is better about those issues:
* no messy interdiff files are posted, the complete history of the patch is available as Git commits in the pull request.
* Code review is easier - no Dreditor needed, just visit the files changed tab of the pull request, with a colorful diff plus the possibility to comment inline.
* Other contributors can easily pick up the commits from the pull request if it would get abandoned by the original author. For the first time we have patches with a Git history!

And some amendments:
* The commit message creation of Dreditor can be fixed by recognizing Github Sync.
* it is not Github Sync's fault that larowlan tested the commenting functionality. When I add a "test" comment to an issue that is noise, too.

So let's keep experimenting a bit longer, please.

Can you at least switch it to using your own account and turn off public access while you polish it? As you say, people can install it themselves if they want to. Or advise people that they should only submit patches to issues specifically designed for testing this (and yes, you should take responsibility for any noise generated while people test it, the noise wouldn't be there if the project wasn't).

There have been some strong negative reactions to this project (and not just chx and the comments above, major contributors have expressed frustration in irc too). Even if it becomes a widely used tool, you're going to find it easier to win those people over with a cautious introduction, compared to messy comments appearing all over issues they're trying to work in.

Is the shared account thing solvable without everyone handing over their drupal.org passwords?

no messy interdiff files are posted,

Not having those "messy" interdiffs is a major reason this frustrates me.

Code review is easier

That's complete BS. I am working with the drupal community on drupal.org, which is where the committers, reviewers, repositories, and everything are located. Why would I want to have to click through to github?

@ianthomas: what would like to polish? Please post bugs and feature requests to https://github.com/klausi/github_drupalorg/issues
In theory you could solve the problem if people would hand over their d.o passwords to me/my server, but I really don't want to do that.

@timplunkett: no need to call it BS, real counter arguments usually make more sense. I can see that people are uncomfortable with using an external service, but that is not a technical argument. Please see the issue summary why you would want to click through to Github: "Code review comments on Github directly in the diff of a pull request are superior to Dreditor reviews because all reviewers can see each other's comments at the same location."

Anyone else in support of experimenting a bit longer with Github Sync? Looks like most people are against it now, so otherwise I will switch it to my personal account and disable issue updates on behalf of other users in the next days.

I and others have posted several problems in the comments above, but it basically boils down to "someone only using drupal.org should not be significantly inconvenienced by the github_drupalorg scripts". Some of the issues I've mentioned (e.g. the hiding old files) may be impossible to fix and may be outweighed by the benefits of github over drupal.org+dreditor.

Others are more serious, the big blockers being that posts are attributed to the wrong user account and that no interdiff is posted.

Code review comments on Github directly in the diff of a pull request are superior to Dreditor reviews because all reviewers can see each other's comments at the same location.

If you're reviewing a single pull request on github only then I agree, but it'll get very messy if different people work on a patch so you might have two pull requests and a patch directly uploaded to drupal.org, each with their own reviews. How do you handle responses to comment, and comments being marked as addressed? Is it possible to change the status of an issue at the same time you do your review, or will that require a followup?

I think these are probably unsolvable without moving to github fully (and even that doesn't solve the multiple pull requests issue). A dreditor-style solution where the review is pasted into the comment box might work as a compromise.

I would like to see interdiffs posted, so that those that want to review as they have can, and those that want to go to github, can choose to do that.

please disable the commenting. I really find it unhelpful and inappropriate.

@pwolanin, can you clarify what about it you find unhelpful and inappropriate? If it were in klausi's name (or the name of other people) would you also find it inappropriate? Just to be devil's advocate, I find comment #41 to be rather unhelpful.

I find it inappropriate for a non-personal account/bot to be posting unattributed comments.

If klausi or anyone else has any automated way to post his/her own actual relevant comments under his/her own name it wouldn't be visibly different from posting the comment form.

I think if:

1) It posted using a person's account, not a generic name.

2) An interdiff was included automagically.

Then most issues for d.o-only users would go away. Code discussion hasn't been solely on d.o for years: IRC conversations with after-the-fact summaries (sometimes) are already how major reviews happen more often than not.

@pwolanin: of course the all comments posted by Github Sync are attributed to the orginial author, every comment posted by it clearly mentions that.

But yeah, the next step will be to switch it to my personal account.

Ok, updated my webhook implementation to use my user account. I also disabled the comment synchronisation and updated the README at https://github.com/klausi/github_drupalorg

Being right (I don't agree you were wholly right) doesn't entitle you to provide that perspective in a rude way. First of all, it makes you less successful in achieving your own goals, so it's self defeating. I hope you learn that lesson some day, regardless of what communities you work in. Second, our community demands interactions based on respect for each other. We don't say it's out policy some days but perfectly fine to skip others. It's our single policy.

You would serve yourself well to either engage constructively or stop making snide, fatalistic comments. There's a lot of constructive feedback in this thread for how to enable hundreds of developers to work to make Drupal 8 better in the way that suits them best (i.e. on github,, or on d.o, or both maintaining credit and centralization of resources). Let's focus on that.

I did not read the comments above, so basically took the information that I would have with a github sync post without going to the 3rd party pulls and forks to read the discussions. So some of these points may have been said above, but that is just a taste of what I expect to happen with github sync. Here is why I'm concerned about this:

- This will fragment discussions, as a reviewer, it will be significantly harder to asses what is going on, I would need to explore and find all the forks and pulls which may have commits that have been merged into the current version.
- I have not seen the github sync user post interdiffs, so I would need to inspect the commits independently
- Lets say I can/should ignore the discussion elsewhere because the issue has all the info. That would require human solutions, ie. people actually keeping up to date issue summaries. Which is not happening here either. Eg. there is no crosslink to an issue where dreditor would be updated to consider the user name from github sync comments.
- This adds significant infrastructure / processes to learn to whoever wants to contribute to issues that use this system in whole or in part. Do those people also need to have github accounts and understand pull request / review / commit processes on github?
- How do I as a reviewer interact with someone posting with github sync? Do I post a review on the issue? Where do I get answers to that? On github? On the issue? How will a core committer figure out what happened, in what order by whom?

Trying to answer a bit from my point of view:

• General discussion should of course be on drupal.org in the issue. Detailed technical code review (currently the dreditor drive by shootings) could be on the pull request diff directly on the code, multiple people could comment there in one location. This would be the opposite of fragmentation - it would bring code reviewer comments closer together.
• Obviously I underestimated how much people like the interdiff Drupalism. I like commits more, since they also state what has been changed in their commit message. And larger changes to a patch would usually be split into more meaningful chunks, not one giant interdiff. But I guess this is a matter of taste
• Contributors do not have to participate on github on an issue that uses github sync - they can just work on the patches that have been posted along the way. No, they don't have to understand github or pull requests or anything else. At the end of the day only the submitted patch to drupal.org counts. Example: dawehner improved my patch in #2180425: PathBasedBreadcrumbBuilder should catch all exceptions from routing, I later merged his patch back into my github pull request. Relatively peaceful co-existence, people can choose which workflow they like.
• You can interact with people using github sync where you want, but this would be my advice: minor technical points such as typos, naming, spacing on github (keeps the drupal.org issue clean) and general discussion and major architectural points on drupal.org. That would also ease the life of core committers, since we would have the more relevant parts on the issue and the boring details elsewhere.

But yeah, having now another place besides the issue queue, IRC and Twitter for potential comments could be challenging. Although we managed Twitter and IRC quite okay so far, since we all acknowledge that the issue queue is the canonical place where the most important parts need to be captured.

My concern wasn't the commit-based workflow, but rather the introduction of an alternative workflow and how that would fit in with the interdiff-based workflow (poorly, at the moment). Personally I'm in favour of a wholesale move to github or similar (possibly bitbucket+JIRA, as github only has a basic issue system).

The big difference between github and irc, twitter, meetups, phone calls or whatever, is that github is a permanent record that you can look up by issue, which makes it a competitor for being the canonical place. Everything else either doesn't keep a record, or keeps a time-based record.

Thank you all for working through this issue, and bringing it to a workable resolution. As the issue was closed by the community, the Technical Working Group will not be providing an official position on this topic.

From a 'guiding principles' perspective, the current TWG position does place value on ensuring that any community contributions are easily attributable to the individual making that contribution ... and as it appears that is now happening here, we thank you.

Those who are interested in the issue of bots / tools posting directly to drupal.org are invited to review #2328093: Establish policies for external bots or tools that post or modify content on drupal.org.