I merely mention for historical reasons.
territory. They would get rather short with others who touched it
causing edit wars and emails to me. It was then challenging to
pages. Removing the Author tag from book pages was one solution and
response to credit.
challenging thing. Where does writing and editing intermingle. When
Credit has always been a challenge. It was more so in the Drupal
still not significantly improved from those days on Drupal 6.
Post by Ariane KhachatouriansFWIW I just finished a HUGE tidy of the D7 install guide last night (except
for the multisite section) that I'd been working on for about a month. It is
in infinitely better shape now but definitely needs a little more work and
then some more reviewing. (All my notes are on the issue
http://drupal.org/node/538054.)
The critical D7 to-do list jennifer and I have been keeping up to date is
here: http://drupal.org/node/515870.
The highest priority task is updating and writing the missing API docs. Next
is all the D7 handbook work (install and upgrade guides, and docs for the
new modules).
A side not, I got "permission" as such from Earl (merlinofchaos) to tidy and
update the views section of the handbook (most of their real docs are in
advanced help, but the handbook section has become a dog's breakfast and
needs work). So that's marginally on my radar of medium priority.
Most module maintainers are thrilled to have even semi-complete docs dropped
in their laps for a review. If uncertain, ping them on IRC or by email and
collaborate.
I know maybe recognition is a big motivator for some, but I think we have to
somewhat focus on why we're really doing this - because we want to help
people use and create Drupal. And the way we do that is just to take
initiative and GSD (pardon my language, Get Shit Done).
Once we've got the critical D7 stuff off our plates, we can refocus on
docs.drupal.org and other improvements such as how to give credit.
A.
Post by beckysue shI'm taking a walk on the wild side.
I owe clean up on d7 installation directions.
I owe clean up on d7 upgrade directions.
I owe jhodgdon two patches on drupal core now that I am less ignorant
of how to run eclipse.
I took a side jaunt over into the biblio module to write up
documentation for advanced help and integrate it into their 6x2dev
version.
I'm currently developing a biblio companion module (biblio
collections) based on cloned code from another module.
I agree completely that it takes different personality types.
Offering to provide advanced help integration into a module was very,
very well received. While I'm not sure we can convince a
'programmer' to write documentation, this particular one (rjerome) was
very willing to critique things once the docs were provided. He also
asked questions about biblio docs on d.o., organization of same,
enhancements to it, etc. He also pointed out he didn't have edit
access to the biblio documentation pages on d.o. since things have
begun moving around.
Perhaps we could consider mini-sprints for incorporating advanced help
into contributed modules as a segway into engaging the contributor
module owner into helping with docs.
We also did a survey last year (2009) regarding how to say thank-you
on drupal. I analyzed the info and sent it to add1sun just before she
needed a break to handle personal stuff. Perhaps we should revisit
that as well.
bekasu
Post by Ariane KhachatouriansAs much as I really do agree that it would be great to have some more formal
acknowledgment, and that it should certainly be a consideration as maybe
another phase of the redesign and development of docs.drupal.org, in the
meantime, I think it's a bit of a matter of self promoting.
- List your contributions on your d.o profile
- Blog about your achievements
- Add it to your bio on your company's website
And never negate the worth of Drupal karma - I have seen my perceived worth
and the amount of respect I get in the community grow significantly through
working on docs.
But yes, let's put that on the agenda of things to work out - why not file
an issue?
A.
Post by Shai GluskinFolks,
Re: Josh, given that at your first glance you thought there was a security
problem... even though it was from not reading thoroughly, I'm concerned
An alternative, detailed here, is for the *site developer* to place PHP
code into the "PHP Code" fieldset below the allowed values box on the
textfield set-up page in order to populate the list by parsing the text
stored in a node.
I've removed the credit at the bottom.
But it raises a larger issue... which is how to promote more documentation
writing within Drupal.
By comparison... let's look at developers in the Drupal ecosystem... For
those who want to get at the heart of the beast, who have LOTS of patience
and not much interest in getting credit, there is Drupal core. For
those
who
want to be in charge, have less patience and want to be king of something...
they can be involved in module development. Some folks do both, but it seems
like there is a personality difference in the two types of people. So the
question is, "How can we make writing documentation more motivating form
more people to want to participate?"
Shai
On Mon, Feb 1, 2010 at 8:12 PM, Ariane Khachatourians <
Post by Ariane KhachatouriansJust had a skim.
I would agree and say it's pretty well a policy not to credit yourself on
the pages (though I would keep the links to the other two pages if
they
are
useful as references). It does indeed discourage others from updating the
pages, and sort of clutters up the pages if a lot of people have
worked
on
them.
If people want to know who's worked on pages, all they need to is look at
the revisions tab.
Otherwise, formatting and such looks pretty good.
A.
On Mon, Feb 1, 2010 at 5:10 PM, Joshua Brauer
Post by Joshua BrauerUm... OK so I didn't read this correctly... The PHP issue isn't what it
looked like at first glance....
Thanks,
Josh
--
Follow me on Twitter: http://twitter.com/jbrauer
Any user with the permissions to post PHP code to your site has
permissions much greater than 'administer content types'. In fact
they
can
give themselves 'administer content types' permissions should they choose
to.
I thought we had a policy against the credit links but maybe it's just
been a discussion. In short, in my opinion, the credit links discourage
others from editing pages as appropriate, clutter the page, and become a
problem as to "at what point when I've edited the page should I
remove
those
credit links from two years ago".
Thanks,
Josh
--
Follow me on Twitter: http://twitter.com/jbrauer
A friend of mine (he's newish to Drupal, this is his first handbook
for the Reference: snippets section called, "Managing a CCK allowed
values list without granting 'administer content types' access."
It's at: http://drupal.org/node/701774
1. Tell me there is a much easier way (I'm dreading this one...
hope
that is NULL)
2. Review the handbook page and make improvements (it's directly
editable by all d.o. users as are other handbook pages).
3. Give feedback on the "credits" at the end. Laurance in writing
it
up listed our names as creators of the tutorial. That's pretty
rare
on
handbook pages, isn't it? I'm wondering if that is a part of d.o.
culture
that might be worth changing. I understand that handbook pages
evolve
with
their wiki style. But the revisions list preserves that. And
module
pages
often have "originally written by" lines in them even as the new
maintainer
identifies him/herself. What do you think.
Best,
Shai
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/
--
Pending work: http://drupal.org/project/issues/documentation/
List archives: http://lists.drupal.org/pipermail/documentation/