search

backdrop-ops / contrib

Apply to join the contributed code developer team.
23 stars 16 forks source link

Google Analytics #12

Closed alexhass closed 9 years ago

alexhass commented 9 years ago

I've ported GA to Backdrop. Can I get commit access to contrib for this, please?

quicksketch commented 9 years ago

That's great @yamlfd! Could you post a link to the port? We usually put them up on Github in a personal account before transfering them over.

A few things to keep in mind:

We're really excited to see your port! We just like to have a small bit of guidance before letting loose in the contrib repository. Thanks!

alexhass commented 9 years ago

I'm the maintainer of Drupal GA...

Please grant commit access to contrip repository so I do not need to commit somewhere else first.

quicksketch commented 9 years ago

Hi @yamlfd, it's a bit difficult to identify you from your Github profile. Are you hass or budda from Drupal.org?

It'd still be handy to review the module before it gets added to the Backdrop contrib repository. Github allows you to transfer entire repositories between accounts, so it's not much trouble to commit it in one place then move it later.

alexhass commented 9 years ago

Budda is an inactive maintainer of ga... for about... 7 years?

quicksketch commented 9 years ago

So hass it is then. Could you still push your ported module to your own account so we could help get the basics covered before putting it into the Backdrop contrib group? Thanks!

alexhass commented 9 years ago

I think we can commit the code and optimize later. Except the variables conversion, everything is done. I do not need a review.

quicksketch commented 9 years ago

Hi @yamlfd, we really prefer to give modules the most basic spot-check before putting them in the contrib repository. After you push to your personal repository, you can use Github's settings page on the repository to move it into the backdrop-contrib group, so you don't even need to upload it twice.

I think we can commit the code and optimize later. Except the variables conversion, everything is done.

Agreed that you don't need to do a 100% conversion, at this point use of variable_get/set() is okay, just discouraged because its config can't be moved between environments.

But we'd still like to do a basic review first.

alexhass commented 9 years ago

As the maintainer of the module I do not understand this. We also do not have such a bad process on d.o. I'm able to care myself about code quality and bugs. Do you plan to block projects from the repository all times this way?

quicksketch commented 9 years ago

We also do not have such a bad process on d.o.

The process is much more involved on d.o. You only have to go through it once. See https://www.drupal.org/node/1011698.

Because Backdrop has subtle differences from Drupal, we need to do a basic check to make sure these differences are understood. Every committer on drupal.org must go through the process of a full code review. We're just asking for a spot-check. Your account on drupal.org (and mine too actually) were probably granted access long before these processes were put in place. I can promise you that the amount of review we're doing is much less than if you tried to create a new account on drupal.org today.

We plan on giving the first project of every new contributor a basic review before letting them have access to the entire contributed repository, but it's not as painful as you're making it sound. Since you've opened this issue, two other contributors have applied and been accepted (https://github.com/backdrop-ops/contrib/issues/23 and https://github.com/backdrop-ops/contrib/issues/22) within hours. All you have to do is push your code, get it reviewed, and then agree to the guidelines.

alexhass commented 9 years ago

I'd like to commit the module to the backdrop contrib repository. Please grant access to me. I do not like to create it first somewhere else.

quicksketch commented 9 years ago

Let's use an analogy to describe the current situation.

We're all on a plane together. An individual is sitting in the exit row. It's is a great place to be, it's more comfortable and a lot of airlines charge more to have a seat there. But in exchange for sitting in the exit row, you have to be able to agree to help the crew in the event of an emergency. Additionally, it's required that you put your luggage in the overhead or clear the foot-space of your items before take-off. If a passenger repeatedly refused to clear the area around them before the plane took off, do you think the flight attendants would allow that person to sit in the exit row? Do you think they would believe the person if they agreed to help in the event of an emergency, when that person won't cooperate with their luggage?

We've asked to do a simple spot check on your code ("clear your luggage") 5 times now, but each time you've refused to put your code up because it's inconvenient to you. How are we supposed to believe you'll be cooperative with the security team ("in the event of an emergency") if you refuse the most trivial of requests?

At this point, I'm going to talk to @jenlampton about what to do about this application. We'll decide together as the Project Management Committee.

docwilmot commented 9 years ago

@quicksketch, you're a very patient man. kudos.

alexhass commented 9 years ago

That is a different situation... You require me to publish my work. That's fine - I'd like to do this! But you require me to publish it in a place where nobody see it. I do not know why. I'm fine in not creating a release before this review and I never refused to work on security issues. I can also send you the code by emal, but I do not like to publish it on foo for a review if the development place is the bd contrib repository. If there is anything wrong in the code I'm fine to change it. There is a issue queue than where bugs can be reported.

jenlampton commented 9 years ago

We actually require the opposite. Code needs to be posted in a public repository (where everyone can see it) preferably under your own GitHub account. Email is private, so is not sufficient.

It has been explained to you several times why the review step is necessary, I'm sorry that you still do not understand: Backdrop is different than Drupal, and GitHub is different than Drupal.org. We want to make sure that you understand the differences, and if not - we'd like to help guide you through them. This step is mostly for your benefit, please take advantage of the help we are offering.

Saying that you will collaborate later ("I'm fine in not creating a release before this review"), or that you have collaborated in the past ("I never refused to work on security issues"), is not an excuse for refusing to work with us now.

Backdrop Contrib is not the "development place", development can happen anywhere. The contrib group is the place where official projects will live. It's where people will be going to find modules, themes, and layouts to use on their own sites (until our website is ready) and it's a place we can collaborate.

We have also explained that it is very easy to move this repository into the contrib group after you are approved, so there is very little extra work involved, and we all struggle to understand your hesitation.

We are not looking for perfection in this review. All projects will have something wrong with the code at some point, and because of this, another one of our requirements is that the GitHub issue queue be enabled for official communication. Your module is not special in this respect.

alexhass commented 9 years ago

Jen: why are you saying development place is not the contrib repository? How should I download the latest version if it is not there? I have seen a broken "token" project in public area just as one example. The projects are mostly dev projects. Why exists these projects in contrib if this is not a development place? It looks like unstable DEV releases in Git on d.o.

Why are you not simply create the project namespace in contrib and grant me permission on it? Why should I use 5 extra steps to have this if there could be just one? This is waste of time from my point of view. No idea why I should develop somewhere else in a hidden area.

What is different to two people review in private and grant access to contrib vs. two people review in public and grant access to contrib? As only you two make the decission there seems to be no difference except I have 5 times more work.

jenlampton commented 9 years ago

We are denying your application to join the Backdrop Contrib group at this time.

We are looking for a few very important things in new contributors to the Backdrop project, solid communication skills, willingness to collaborate, and respect for others.

If security issues arise for any project in the contrib group, we will need to be able to communicate and collaborate to solve the problem, and hope to maintain respect for one another in the process.

It seems like we are having some problems communicating in this thread:

We're concerned about your ability to collaborate with others:

We have seen general lack of respect for other developers:

We feel that showing disrespect to other contributors, failing to communicate clearly in the issue queue, and failing to collaborate with other members of the community would be problematic for a member of the Backdrop contrib group.

We also believe that most of your misunderstandings may be resolved with more experience. Please spend some time over the next month learning how to use GitHub, learning to use Backdrop, and watching how this community operates.

You are welcome to apply to join the Backdrop Contrib group again in one month. Please open a new issue any time on or after February 28th, 2015.

alexhass commented 9 years ago

In spite of several explanations, you still do not understand why we are requesting a quick code review.

You have not explained why.

In spite of a clear statement to the contrary, you believe that we are asking you to post your code in private.

No. I never said that you like me to post in private. I'd like to do it in private for initial review only.

In spite of several explanations, you still do not understand that a repository can be easily moved from your own GitHub account to the Backdrop Contrib group.

No. I understood this, but I do not like to create a repository in my account to spend my time later on moving the project. The project should reside in contrib from day one. There is no reason to move data outside. I still do not understand why contrib is not the place for development (you said this) and I received no feedback to this.

We have asked you to post your code several times. Whether you understand why or not, a big part of this process is working with us.

I'd like to post my code, but you do not grant permission on contrib to do so. That is the opposite.

Your continued refusal to post your code makes it appear as though you are not interested in receiving a code review, or collaborating with other developers.

No. You can review the code and suggest optimizations after the code is in public contrib DEV repository. In future we have the issue queue to post patches and review, but the initial commit need to be done first to publish the code. There is also no GA issue queue I could post the code for review before the project has been created, too. You process of accepting developers seems not optimal.

Saying that you will collaborate later, or that you have collaborated in the past, is not an excuse for refusing to work with us now.

Nope. I collaborate, but you do not help me getting the code into public.

Referring to other projects as "broken" or "unstable DEV releases" is not a very nice thing to say.

It is just the truth - that is all. I think I can say this straight as a reviewer. I do not butter token up first and than tell the truth. I opened a bug case to help getting the bug fixed, but got zero feedback yet. The module is still broken and causes several warnings and breaks in my tests. If I cannot post my code the token developer may find it very difficult to identify the root cause as he could test with GA. I tried to understand the root cause, but it seems difficult to me.

If there would be a proper review process such quality wouldn't be there. It may hard to get told the truth, but it is real. If quality is not the intention of the review process - what is the intention?

You feel like it's a waste of your time to create your own GitHub code repository. Correct. 5 times more work. We can discuss longer or just do it and add the project to contrib.

It would similarly be a waste of our time to create this repository for you.

Getting one of the top 10 Drupal projects or Top 3 of Backdrop into the repository is waste of time? I guess not many sites will accept running without GA. You may reconsider this again.

Please also consider that it has already been an extreme waste of our time repeating ourselves in this issue.

That's only because you do not provide long term solutions I'm interested in.

Before you do not explain why a process to get into the contrib reprository is so complicated (personal project / review in public / no QA / move project) it may not accepted. The other complains do not fit to me, sorry. This has all only be said because you make all so complicated for nothing.

If someone is interested into the project he should better chime in to get things committed.

jenlampton commented 9 years ago

If you would like to be a maintainer for the Backdrop Google Analytics module you are welcome to re-apply to join the Backdrop Contrib any time on or after February 28th, 2015.

In that time, please do some of your own research and see if you can come up with satisfactory answers to the questions you are seeking here. Everyone else has been able to figure out the application process with no issues, so we will not waste any more time explaining things.