Nov 06 2018
Nov 06

The TWG coding standards committee is announcing two issues for final discussion. Feedback will be reviewed on 11/13/2018.

New issues for discussion:

Needs love

Interested in helping out?

You can get started quickly by helping us to update an issue summary or two or dive in and check out the full list of open proposals and see if there's anything you'd like to champion!

Oct 17 2017
Oct 17

The TWG coding standards committee is announcing two issues for final discussion. Feedback will be reviewed on 10/31/2017.

New issues for discussion:

Pending ratification

Provisionally approved issues

Interested in helping out?

You can get started quickly by helping us to update an issue summary or two or dive in and check out the full list of open proposals and see if there's anything you'd like to champion!

Sep 03 2017
Sep 03

The TWG coding standards committee is announcing two issues for final discussion. Feedback will be reviewed on 9/19/2017.

New issues for discussion:

Interested in helping out?

You can get started quickly by helping us to update an issue summary or two or dive in and check out the full list of open proposals and see if there's anything you'd like to champion!

Apr 20 2017
Apr 20

Open conversation is essential to the wellbeing of any community. It is especially important now, as we collaboratively determine how to evolve our governance.

This discussion thread is being posted as a place for ongoing conversation about recent community issues and the governance improvements that the community is collaborating on together.

For background information on additional conversations being held, we direct you to:

https://www.drupal.org/community/discussions

...which has links to open community discussion sessions to be held at DrupalCon Baltimore, and that are being held virtually. After those sessions are completed, minutes will be posted to page above.

We encourage you to join us at those community discussions if you are able, and/or to continue the discussion here.

Dec 20 2016
Dec 20

The TWG coding standards committee has provisionally approved 3 coding standards change proposals. These will need to be finally approved and implemented by core before being fully ratified.

The process for proposing and ratifying changes is documented on the coding standards project page. Please note, a change to this process is being proposed to streamline the interaction between the coding standards body, Drupal Core, and the Coder project, please provide any feedback on that issue.

Provisionally approved proposals awaiting core approval and implementation:

Interested in helping out?

You can get started quickly by helping us to update an issue summary or two or dive in and check out the full list of open proposals and see if there's anything you'd like to champion?

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for December 20th. At that point the discussion may be extended, or if clear consensus has been reached one or more policies may be dismissed or ratified and moved to the next step in the process.

Dec 06 2016
Dec 06

The TWG coding standards committee is announcing three coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The process for proposing and ratifying changes is documented on the coding standards project page. A change to this process is being proposed to streamline the interaction between the coding standards body, Drupal Core, and the Coder project, please provide any feedback on that issue.

Announced for final discussion:

Official coding standards updates now ratified:

Formerly announced issues that need an issue summary update

These issues have a lot of support but need an update to formalize the proposal so that they can be ratified and applied.

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for December 20th. At that point the discussion may be extended, or if clear consensus has been reached one or more policies may be dismissed or ratified and moved to the next step in the process.

Aug 24 2016
Aug 24

The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.

Official coding standards updates now ratified:

Issues awaiting core approval:

Issues that just need a little TLC (you can help!):

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for August 30th. At that point the discussion may be extended, or if clear consensus has been reached one or more policies may be dismissed or ratified and moved to the next step in the process.

Jul 04 2016
Jul 04
klausi's picture

Hm, some items on this list appear twice, can you delete the outdated lines? (camelCase issue, PHP 5.4. array issue)

Jons's picture

I'm sure this has been argued over but I just think the format:

if (condition1 || condition2) {
action1;
}
elseif (...)

does not scan well to me, and is contrary to years of use in C, Java, PHP of
} elseif () { style

Also seems a waste of good screen real-estate!

tizzo's picture

The process for proposing coding standards standards changes is documented on the coding standards project page. As per that description, please create an issue there and build support if you have suggestions for changes.

fgm's picture

I added a note about result type hinting on the param type hinting because it is pretty much the same issue. Can't we have it mentioned for code requiring PHP7, just like for scalar param hints ?

greg.1.anderson's picture

This should be obvious enough, but on any issue addressed by PSR-1 or PSR-2, the Drupal conventions should either:

a) Stay as they are
or
b) Adopt the PSR standards (preferred)

For example, the indentation change recommended above for else / elseif is in alignment with PSR-2, and therefore should be adopted.

yurii_2016's picture

change spaces to tabs

in what age are we now? in stone or iron?

tizzo's picture

The process for proposing coding standards standards changes is documented on the coding standards project page. As per that description, please create an issue there and build support if you have suggestions for changes.

Jons's picture

The more picky we are the less people are likely to contribute to Open Source.
Why are we even discussing use of '!=' or '<>' !!

For one thing it means we're focussing on the wrong things, which machines (our compilers) don't care about, so why should we? The general drive of IT is to make machines work the way we like - i.e. make them even more flexible to accommodate different human (creative) approaches, so we don’t want to work in the opposite direction.

The only real need for code standards is in the area or source code control - where we want to see just the changes. So the perspective must be to respect the layout of the author (as we do with written language) within some simple guidelines, rather than insist it's all converted into our way of doing things, in minute detail, before we accept it.

So!

tizzo's picture

The reason we should care about coding standards is that we want humans to be able to effectively parse the code. When we share a set of standards the consistency makes the code easier to read at a glance than when it is varied.

The general Drupal approach has been to push in the direction of consistency to the point where it's as if all Drupal code were written by one hand.

yurii_2016's picture

really, remove this stuff, it is useless and doesn't make sense, it doesnt add and meaning etc

the best way is, you don't force me to add that dot. i want to be able decide - do i need that dot or not

tizzo's picture

The process for proposing coding standards standards changes is documented on the coding standards project page. As per that description, please create an issue there and build support if you have suggestions for changes.

Apr 26 2016
Apr 26
droplet's picture

These proposals will be re-evaluated during the next coding standards meeting

Why Drupal making code style in Private talk? We have 3000 contributors in CORE. Can't allow us to vote on the final proposal. (Let's say Top 100 ? Top 500 to vote ?)

For example:
https://wiki.php.net/rfc/shortsyntaxforarrays

diff group of developers has diff views.

These standards aren't about Security & Code Performance. It need not experts to make a right decision.

jthorson's picture

Coding standards was flagged to the TWG as an area where conversations would happen, then fizzle out, and no actual change would be made ... either due to a lack of understanding over how to make the consensus 'official', or due to an inability for the community to come to a consensus.

The role of the coding standards committee is to facilitate the discussion, and ensure that these conversations are followed through to a conclusion instead of stalling 'ad infinitum'. This does not mean that the coding standards committee is making the decision ... all issues are still debated in open issues, and any and all community members are encouraged to provide their input.

What this announcement means is that the issues either appear to be approaching consensus (and will soon be either marked 'fixed' and ratified into our standards, or closed), or the conversation has stalled on a key issue that the committee would like to see resolved. Consider it a 'heads up' for anyone who might want to contribute to the discussion, but hasn't discovered the existence of the various issues/proposals on their own accord.

droplet's picture

Thanks.

But who and how made the final decision? It's unclear. Can the TWG discuss it in next meeting?

I believed Public discussion only helped us to kick out impossible options. For example:

PHP array [] can't backport to D7. Or some code style bad for GIT history.

After than that

["a", "b" => ["A", "B", "C"], "c"]

OR

[
"a",
"b" => ["A", "B", "C"]
"c"
]

OR

array(
"a",
"b" => ["A", "B", "C"],
"c"
)

it's Apple & Orange.

jthorson's picture

"Announced for final discussion" means that we want to wrap this one up. The process indicates that, after an initial two weeks discussion period, the coding standards committee will review the issue to determine whether i) there is a clear consensus or overwhelming preference, ii) more discussion is needed to resolve the issue, or iii) the discussion has reached an unresolvable impasse, requiring escalation or intervention.

In the case of iii), then the coding standards committee would generate a recommendation; though I wouldn't consider this issue as falling under that category. Otherwise, the "final decision" was made as it always is ... by the community through a process of open discussion in the issue queue ... and the job of the coding standards committee is to ensure that the change/proposal is published and communicated.

droplet's picture

Thanks.

But who and how made the final decision? It's unclear. Can the TWG discuss it in next meeting?

I believed Public discussion only helped us to kick out impossible options. For example:

PHP array [] can't backport to D7. Or some code style bad for GIT history.

After than that

["a", "b" => ["A", "B", "C"], "c"]

OR

[
"a",
"b" => ["A", "B", "C"],
"c"
]

OR

array(
"a",
"b" => ["A", "B", "C"],
"c"
)

it's Apple & Orange.

cosmicdreams's picture

I know that I commented on one of your previous status updates about whether we should move Drupal's coding standards closer to PSR2 by accepting the "open bracket on the next line" rule. See:

Drupal's standard: https://www.drupal.org/node/608152

VS

PSR2: http://www.php-fig.org/psr/psr-2/#4-1-extends-and-implements

Perhaps this was discussed about elsewhere and I'm not able to discover that conversation? Perhaps I'm being ignored and we'll make no progress this year on evolving our code standards to comply with PSR2?

Please let me know how I can be a positive force in this effort

jthorson's picture

I don't recall this particular issue being reviewed at any of the coding standards meetings as of yet ... the first step would be to open a dedicated issue with the proposed change in the 'coding standards' project on drupal.org, so that other community members can have an opportunity to provide their input.

Mar 20 2016
Mar 20

The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.

The two issues being proposed are:

As a follow up on the preceding set of issues now concluded:

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for March . At that point the discussion may be extended, or the policy may be dismissed or ratified and moved to the ‘update documentation’ step.

Jan 22 2016
Jan 22

The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.

The two issues being proposed are:

These proposals will be re-evaluated during the next coding standards meeting currently scheduled for February 5th. At that point the discussion may be extended, or the policy may be dismissed or ratified and moved to the ‘update documentation’ step.

Jun 29 2015
Jun 29
ianthomas_uk's picture

This is clearly a reaction to the recent security flaw, where two major hosts with staff members working on the security team were able to mitigate the flaw for their customers, even when those customers were running unpatched versions of Drupal.

It seems to be targeting two criticisms of that event:
1) These hosts were able to get a commercial advantage using confidential information from the security team. I see no issue with that - it is a small reward for the work they are putting in on the security team. If competitors want this confidential knowledge, they can get it by sponsoring a member of the security team.
2) It expanded the number of people who knew about the vulnerability, and therefore the chance that details would leak before the official announcement. The policy does help here, although there is a risk it will slow the development of a patch (e.g. if the manager refuses to sponsor the time without more details).

Had those hosts not acted how they did, many more sites would have been compromised, with potentially huge implications for those involved. It would also have been a tastier target for attackers, as unpatched sites would have been easier to find.

Proof reading: The term "COI" is used before it is defined.

nedjo's picture

Implicit in this comment is the contention that pre-notifying some groups is potentially beneficial.

I agree there's a conversation to be had around this idea. But it's not the same discussion as the one we're having here.

We would need to cleanly separate what did occur in response to SA-CORE-2014-005 from what a well designed pre-notification system might look like. There's no necessary relationship, and certainly no reason to suppose that the various justifications that have been offered are a sound basis for anything.

opratr's picture

Glad I checked before submitting my comments....basically identical to yours @ianthomas_uk.

+1

Edit: So to be clear, I agree with this clarification regarding disclosure. It's strikes a good balance between the risk of premature vulnerability disclosure and allowing team members to take appropriate measures outside of the team to benefit the Drupal community when an opportunity presents itself.

ianthomas_uk's picture

As written, it's a bit unclear on exactly who could be brought in on the issue. For example, in a large host there will be developers involved in implementing the solution, and an ops person involved in deploying the solution. Should ops people be added to the drupal.org issue? Are they not allowed to be told until the public disclosure? My reading of it is that ops people should not be told, which means no early protection.

IIRC Pantheon's workaround involved filtering the traffic before it even got to Drupal. Is that relevant for discussion on the issue?

Edit: Actually it's a bit more explicit than that. The policy states "We want to avoid ... creating a situation where people use still-private knowledge gained on the team to get an unfair advantage".

That basically rules out bringing anyone else in your organisation into the loop, unless they will be writing / reviewing the patch itself. You can only discuss deploying the patch once it is public.

nedjo's picture

While not without merits, this draft reads as a compromise document, the result of a process that ultimately ducks rather than directly addressing the key issues at stake. That lack of clarity is already evident in the couple of commenters so far, who form very different conclusions.

Rather than elaborating aims that the policy will supposedly address, the policy should just do it: state directly expectations of security team members. This sentence is so ambiguous as to be useless:

Creating a situation where people use still­-private knowledge gained on the team to get an unfair advantage with no regard for the health of the Drupal ecosystem.

Instead, the policy should cut to the quick and begin with clear, unambiguous guidelines for action. Suggested phrasing:

As a security team member:
* Minimize risk that issues will be leaked beyond the team and posted to the public, outside of the release window and before a patch is released.
* Do not use still-private knowledge gained on the team to get an advantage or benefit.

lesleyb's picture

@ianthomas_uk I think COI means Conflict Of Interest; the term has been used earlier but the abbreviation was not introduced then.

The difficulty seems to be people on the security team are in a privileged position. Not only are they aware of a security flaw before any other 'general Drupal user', they are also in a position to patch their own installations before anyone else in the community. By their involvement in the security effort, they are in some state of preparedness for any security issue that arises.

When the advisory is issued, then the 'general Drupal user' is able to read, digest and act on that information - the security team members are already prepared to act on that information. The security team members can, under the remit of the current document, inform their teams a security patch is coming out that must be attended to.

Presumably the security team will also have knowledge of the timing of that release of information so they will literally be able to set their actions in motion the second someone in the security team hits the send button on an advisory notice.

I think this is as much privilege as the security team can allow its members and is reasonable.

Having a patch tested, ready to go and permitting security team members act on it prior to an advisory going out clearly not only leaves the 'general Drupal user' excluded from the benefits endowed by having the security team but also threatens the security of information held by the security team .

I would think the 'general Drupal user' would object to that on both counts.

Although it seems clear - from the outside of the security team - what information can necessarily be shared when and what to do to expand the team where specific expertise is required to find a solution to a security flaw I think the document could be reorganised to better effect. The marketing advice will be useful to team members.

I would drop the first two paragraphs completely. The second two paragraphs, starting with 'This document aims ...' serve as the Aims of the Document.

The main document can then start with an introduction (section 1) at 'In general, information ..' and the three scenarios could be set as sections 2, 3 and 4 with headings within the document - obtaining sponsored time, enlisting expertise from outside the team and marketing advice. Setting these as individual sections now allows any future additions to the document to be handled in the same way. It also allows people to read and find applicable scenario(s) quickly.

The three following paragraphs on how to share information and what to share then deserves its own section, section 5, so it can then be referred to in the prior enlisting expertise section or any other section that needs it.

The COI policy is already in its own section, which would become section 6, and can be referred to from any of the preceding sections.

Hope this helps

Kind regards

lesleyb

May 18 2015
May 18

As mentioned during Dries's DrupalCon LA keynote, the Drupal Community Working Group is now accepting nominations for the Aaron Winborn Award, to honour Drupal community members who demonstrate personal integrity, kindness, and above-and-beyond commitment to the Drupal community.

Nominations are open until Monday 15 June 2015, and the selected recipient will receive a scholarship and stipend to attend DrupalCon with recognition during a plenary session at the event.

Submit your nominations here: https://www.drupal.org/aaron-winborn-award

Mar 23 2015
Mar 23

The Drupal project just turned 14 years old. There are now over 1 million known installations of Drupal, and Drupal.org has over 1 million users. Drupal 8 has over 2,700 contributors (almost three times that of Drupal 7) and over 13,000 commits so far (50% more commits per day on average than Drupal 7). I wanted to take an opportunity to reflect on our current governance structure and try to evolve the Drupal leadership team and decision-making, enable better scaling, and document both the formal and informal processes we have currently in place.

Over in the Drupal core issue queue, I've proposed an evolution to Drupal core's structure and decision-making process which documents how things are currently done, and also proposes some incremental improvements:

  1. Defines roles and responsibilities that are currently carried out by individuals within the core committer team: product managers, framework managers, and release managers. This is done to provide transparency, to help expedite decision-making, and to ensure that these roles are easier to fill in the future, as we can eliminate the requirement for core committers to be “superhuman” contributors capable of doing anything and everything, at all times.
    • This document also adds the concept of “provisional” product, framework, and release managers, without actual commit access, who work alongside the core committers until they gain the necessary experience to play a full committer role.
    • In so doing, the document also appoints two additional core committers—Alex Bronstein (effulgentsia) and Jess (xjm)—who have been playing this "provisional" role for some time now, informally.
  2. Lays out an explicit decision-making framework to make it clear who needs to be involved in what types of changes, and to what degree. This documents the process we already use, but also introduces some changes. The added transparency should make it easier for contributors who are proposing changes to direct their questions to the right people.
  3. Clearly outlines the role of subsystem maintainer (formerly component maintainer) as an active “maintenance” role: performing or organizing regular maintenance tasks: triaging the subsystem's queue(s), reviewing patches in need of review, etc. These responsibilities also come with a more formal opportunity to sign off on proposed changes that significantly affect the subsystem. The advantages to this are additional transparency, delegating and scaling responsibilities, and reducing the workload that currently falls to core committers. Going forward, subsystem maintainers who are not currently active will no longer be listed in MAINTAINERS.txt.

This document builds on ideas that have been blogged about or presented at Drupal events by many people, including Randy Fay (rfay), Larry Garfield (Crell), Cathy Theys (YesCT), Gábor Hojsty, Greg Dunlap (heyrocker), Jess (xjm), Alex Pott (alexpott), Nat Catchpole (catch), Jennifer Hodgdon (jhodgdon) and others. It has been reviewed by numerous people, including the existing core committer team. Special thanks to Angie Byron who has spent weeks helping me co-author this proposal.

Mar 18 2015
Mar 18

For the past few months, members of the Technical Working Group, Drupal.org Software Working Group, Security Working Group, and frequent project application reviewers have been working on proposed changes to the project application review process.

The proposed changes have been posted for public review. https://www.drupal.org/node/2453587

If you have any comments or questions, please add them to the issue. This proposal is open for feedback until the end of March. We will then incorporate the feedback and start working on implementing these changes.

Feb 23 2015
Feb 23

In previous posts, we’ve talked about who the Community Working Group (CWG) is and why we’re here, as well some of the work we’ve done around establishing a process for conflict resolution in the Drupal community.

In this post, I’d like to go into more detail about what happens when folks file incident reports with the Community Working Group, and open up the conversation on how we can more effectively address issues that have a larger impact on the Drupal community as a whole.

Currently, the CWG meets once a week over Google Hangout to go through any issues that might have been filed since our last meeting, as well as to discuss ongoing questions and concerns that have been brought to our attention through various channels (reports, individual conversations, etc.) and the overall health of the Drupal community.

As often as possible, we post the minutes of our regular meetings. By necessity, these are somewhat redacted due to the fact that we are often discussing matters of a sensitive nature that have been shared with us in confidence. We also maintain an email list where we discuss ongoing issues and other things that come up in the time between our regular meetings.

When an issue is filed, whether though the Incident Report Form, via e-mail, or in our public issue queue, it goes on the agenda for the next weekly meeting (if the matter is of a serious and immediate nature, CWG members may choose to take immediate action and/or meet outside our normal meeting time). We discuss each item as a group and come to agreement on next steps, then assign someone to follow-up with the individuals in question. If the issue is about something that doesn’t fall within the charter of the CWG, we may refer the matter to another group (e.g., the Technical Working Group or the Licensing Working Group), or reply back to the reporting individual with an explanation.

In cases where there is a dispute between two or more individuals, our general approach is to first gather as much information as possible from all involved parties. In order to ensure that people are able to share their stories with us in an open and honest manner, we do not share any names or other sensitive details outside the group without permission.

Once we have a sufficient level of detail, we meet again as a group to decide how to proceed. Depending on the situation, this may involve one or more CWG members providing mediation between the parties in conflict or suggesting ways that they can resolve the issue themselves. In cases where there is a clear Code of Conduct violation, we will talk directly to the person or persons who engaged in the violation to help them understand the impact of their words and/or actions and to take responsibility for them.

In some cases, we may receive an after-the-fact report about a situation that has already been resolved. In those cases, we review the incident, decide whether further action is necessary, and keep it on file for reference in case something similar happens in the future.

If this sounds long and drawn out, that’s intentional. Unless an issue requires immediate action, our process is designed to enable resolutions that are as thoughtful and permanent as possible. The Community Working Group is not the “Drupal police” and our role is not about deciding “who’s right” and “who’s wrong” in a given situation so much as it is about helping people in our community work together in a mutually respectful way. While many of the items that we tackle are initiated by issues that are reported to us, our process is not exclusively complaint-driven.

The people who volunteer their time serving on the Community Working Group are people with backgrounds in community leadership and conflict resolution who all have been working in the Drupal community for years. We believe that a culture that encourages healthy debate and disagreement is a big part of what gives the Drupal project and community its strength. What we are primarily concerned about are destructive conflicts that violate our shared community values and make the Drupal community a less welcoming place for everyone.

To that end, we’re looking for the community to help us shape our process for addressing systematic patterns of disruptive behaviours that have an impact that goes beyond just those individuals who are directly involved. Please read our proposal and give us your thoughts in the comments section. You can also share your thoughts privately by e-mailing us at drupal-cwg [at] drupal.org.

Thanks!

Jul 07 2014
Jul 07
webchick's picture

An alternative is the drupal-cwg [at] drupal.org email address, as documented on https://www.drupal.org/governance/community-working-group.

We chose to use Google Forms because a wide variety of people about whom conflicts may occur have very high-level access to Drupal.org. A neutral third-party service doesn't have this problem, although I totally get why some have ToS concerns with it.

DamienMcKenna's picture

Could we please have that email address added to the top of the Incident Report form, just to make it obvious for people? Thanks!

kattekrab's picture

I've edited the form and updated the issue.

https://www.drupal.org/node/2299737#comment-8950891

Would be good to get some sanity check eyeballs on it though!

Thanks all!
@gaele - for raising the question
@DamienMcKenna - for the suggestions.
@webchick - for adding to the queue.

jhodgdon's picture

You asked for "sanity check eyballs" on https://www.drupal.org/governance/community-working-group/incident-report

I have a few comments:

a) There is a very large wall of text at the top. Maybe it could be organized into bullets or sections or something? [see below]

b) You might also want to take a look at the descriptions for the Who/What etc. questions. They are a bit repetitive.

c) The "Who" question also has a mix of questions (ending in ?) and ... sort-of questions (ending in .) which turned me off.

d) "Please include links or quoted text if relevant." is under "where". Um... I think that would be under "what"? At least the "quoted text" sounds like a "what" not a "where"? It's kind of confusing what the distinction is.

So... Here's my suggestion for the top. Items in [] are my notes on the edits.

The community working group (CWG) upholds the Drupal Code of Conduct (DCOC). See:
- https://drupal.org/governance/community-working-group
- https://drupal.org/dcoc

[made this a bullet list]

Reporting incidents to the CWG

[header added]

This form can be used to report incidents that may breach the code of conduct, or to report non-code, non-technical issues that can't be resolved between members of the community.

Alternatively, you may email the CWG directly: [email protected]
Please make sure to include as much information as you can by answering the questions in the form in your email. [note: small edit in this sentence]

Incidents to report elsewhere

[added header, and this information came from elsewhere on the page]
IMPORTANT: If you are in any kind of immediate physical danger, please contact your local authorities.

Technical disputes should be raised with the Technical Working Group. Personal disputes that have arisen out of technical issues can be brought to the CWG.

https://drupal.org/governance/technical-working-group

Notes about incident reports

[added header, and the information here elsewhere on the page]
We hope you've tried to resolve issues between yourselves. If that failed, we hope that you reached out to fellow friends and colleagues in the community to help mediate your dispute. This form should only be used when those steps did not lead to resolution.

These incident reports are shared with the immediate members of the Drupal Community Working Group and are kept confidential. In some cases we may decide it necessary to make a public statement. In that case, the identities of all involved will remain confidential unless there are strong reasons, or mutual agreement they should be revealed.

Builder of Drupal sites and modules, and Drupal tutor - http://poplarware.com
Drupal Core maintainer for documentation

kattekrab's picture

Thanks Jennifer - really useful review and patch.

Going to paste this into the issue https://www.drupal.org/node/2299737

Let's see if we can tighten up the wording around those questions too.

Patrícia Jyotsna's picture

Hi, I heard about Drupal is now a growing community and knowing that the mentored sprints was attended by many to listen to tools presentation is such a very successful one. In relevance to this, I am with you to say that we must be aware in keeping our shared principles and values in mind when interacting with others to be able to attain an inspiring event like the Drupal sprints at Amsterdam.

May 09 2014
May 09

Greetings from your friendly neighbourhood Drupal.org Software Working Group!

https://drupal.org/node/2261945 has a proposal + mockups on a new way to handle feature requests for Drupal.org in order to help both the Drupal.org Software Working Group and other working groups prioritize the feature roadmap for Drupal.org. Since this tool will become the method through which the Drupal community (in the widest sense of the word) makes known their Drupal.org needs/wants/desires, we'd love to hear your comments and feedback on the proposal.

Community feedback period is open until May 18th, as we're hoping to have an initial version of this tool ready by Austin.

Mar 27 2014
Mar 27

UPDATE: The policy has now been adopted by the community working group. It lives here: https://drupal.org/conflict-resolution (now with pretty URL!)

For some time we've had a bit of unfinished business around the Drupal Code of Conduct around how we manage and respond to conflict.

The Community Working Group has drafted a policy and is now looking for community feedback over the next 2 weeks. Please check out the draft in the drupal-cwg issue queue.

https://drupal.org/node/2227717

Mar 17 2014
Mar 17

Michael Hess, Greg Knaddison, Mori Sugimoto, Ben Jeavons, Matt Chapman, Angie Byron and myself have been working on the charter for the Security Working Group (DocWG). The mission of the SecWG is to ensure that Drupal core and Drupal's contributed project ecosystem provide world-class security, and to provide security best practices for site builders and module developers. The work is part of our work on evolving and streamlining the Drupal project's governance.

We just shared our proposed SecWG charter, which has also been run by the existing security team, and now we are looking for feedback and input from the community before formalizing it. We hope to finalize this within the next month, so that leaves some time for community feedback.

Mar 14 2014
Mar 14

In early 2013 our fearless and benevolent leader, Dries Buytaert, formalised a governance structure and started a number of working groups for the Drupal project as a whole, and for our home on the Web, Drupal.org.

Governance Structure Diagram

The Community Working Group's job is to "Guarantee a friendly and welcoming community for the Drupal project by upholding the Drupal Code of Conduct."

In 2012 Randy Fay, a longtime and significant contributor to the Drupal project, wrote a series of blog posts articulating some of the challenges of informal governance structures like ours. If you really want to know the full story behind the creation of the community working group, you should start with Randy’s blog, as well as this proposal that came out of a governance sprint held in July that year.

The aim of putting this governance structure in place is to help the Drupal community deal with the challenges of scale. Formalising roles and teams that already exist in the project supports the work of contributors "doing" in the do-ocracy, and provides more support to those people already actively engaged in community issues.

Dries asked Angela Byron, Roel de Meester, George DeMet and myself to form the first Community Working Group.

Angela Byron Angela is a long-time "cat herder" in the Drupal community who frequently gets drawn into a conflict resolver role and has helped the community through some "meaty" topics such as the CVS to Git migration, and five major Drupal core releases.

Roel De Meester Once upon a time, Dries asked him to look after Drupal.be, The Belgium community website. Nowadays, he's interested in connecting people and ensuring that new members find their way in the community. He's known for his no-nonsense approach and collaborative nature.

George DeMet George is a Drupal Association Advisory Board Member, chair of the Drupal.org Content Working Group, co-chair of DrupalCon Chicago, and one of the folks who helped develop the DrupalCon Code of Conduct.

Donna Benjamin and Me? I was one of the first people elected to the board of the rebooted Drupal Association and I'm really passionate about the non-code aspects of maintaining an open source community.

DrupalCon Prague was a milestone for the group. Lisa Welchman gave a keynote address on the importance of governance for communities like ours. Some people came away from her talk scratching their heads and asking questions.

Why is this relevant to a software project like ours?

In essence Lisa Welchman reminded us that there is no code without people. It is the people, and not the code that define the Drupal community. We have good processes for managing the development and quality of our code. We still don’t have great processes for how we support and acknowledge people and their contributions.

Lisa spoke about a giant fungus as a good analogy for web governance, but also for an open source community like ours. She asked "How do you grow something to be big, that maintains its integrity and maintains its identity?" Lisa suggests that standards and a stable environment are key.

For our code we have coding standards. For our community, we have a code of conduct. That code of conduct represents the foundation of our social standards.

[Photo: Amazee Labs]

In Prague we also held the first Drupal Community Summit. A group gathered to focus on how we might tackle building a conflict resolution policies and processes for the Drupal community. Could we create something flexible enough to apply to all the kinds of conflict we see in our community? How can we acknowledge that conflict itself can be a good thing? We explored questions like these and listed the sorts of conflicts we might need to handle. https://drupal.org/node/2116441

The community summit was a great success, so we'll be doing it again at DrupalCon Austin. https://austin2014.drupal.org/community-summit

[Photo: Amazee Labs]

I'll write a series of follow up articles about our ongoing efforts to define, refine and field-test policies and processes on how the community can deal with conflict and complaints.

We can't do this work alone. We need a team of people willing to help. Many people are already doing this kind of "work" in our community, if you are, please let us know! Or maybe you're doing it and don't realise you are.

If you are someone people look to to smooth things over when things get heated, or someone with experience in conflict resolution outside open source communities, then please get in touch with the Community Working Group. Tell us

  • What are you doing?
  • How can we support you?
  • How can we amplify your effort and successes?
  • How can we improve?

This is Drupal, so of course we have an issue queue!
https://drupal.org/project/drupal-cwg

We also have a discrete incident report form only seen by members of the community working group.
https://drupal.org/governance/community-working-group/incident-report

Please look through our issue backlog. We’re looking for people willing to help us mediate disputes, formulate and refine community policies, and look for ways to build a community culture we can all be proud of.

Feb 06 2014
tvn
Feb 06

The Drupal.org Software Working Group is looking for volunteers to take on leadership roles and help guide development of the Drupal.org Community Tools, which include Forums, Drupal Planet, User Groups (groups.drupal.org), User Profiles, User Dashboard.

Basically, this team is about all the tools community uses for things other than code development. Historically all these tools were separate from each other and there was no clear vision or single roadmap/plan. We hope that by improving the decision making structure we can expedite development of these tools and ensure they meet community needs.

Take a look at the current proposal for the scope, roles, responsibilities and authority of the team.
For the full background see this post.

The Software Working Group will appoint the new team by the end of February, 2014. Right now we are looking for candidates for the roles on the team. Interested? Know someone who you think would be a great candidate? Let us know by February 20!

Dec 19 2013
tvn
Dec 19

The Drupal.org Software Working Group is looking for volunteers to take on leadership roles and help guide development of the Drupal.org Developer Tools, which include Projects (project pages, releases, issue queues, change records), Version Control (git repositories, commit logs, repository viewer etc.) and Testbots.

This is by far, the most important part of Drupal.org. It's that section of the site which lets the community do their main thing - develop Drupal. It is, therefore, very important to have a clear decision making structure to ensure that we can deploy changes and improve the section to give Drupal contributors all the tools they need to do their jobs.

Take a look at the current proposal for the scope, roles, responsibilities and authority of the team.
For the full background see this post.

The Software Working Group will start appointing the new team on January 15, 2014. Right now we are looking for candidates for the roles on the team, specifically for Product Owner, Project Manager, UX Lead.
Interested? Know someone who you think would be a great candidate? Let us know!

Oct 10 2013
Oct 10

Webchick, batigolix, jhodgdon and leehunter and myself have been working on the charter for the Documentation Working Group (DocWG). The mission of the DocWG is to ensure that Drupal Core and Drupal’s contributed project ecosystem have excellent documentation-related guidelines, tools, and processes in place. The work is part of our work on evolving and streamlining the Drupal project's governance.

We just shared our proposed DocWG charter and are looking for feedback and input from the community before formalizing it. We hope to finalize this by October 23, so that leaves about two weeks for community feedback.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web