Communicating your project is an essential step for getting users. Here I summarize my experience from working on several different projects including KDE (where I learned the basics of PR - yay, sebas!), the Hurd (where I could really make a difference by improving the frontpage and writing the Month of the Hurd), Mercurial (where I practiced the minimally invasive PR) and 1d6 (my own free RPG where I see how much harder it is to do PR, if the project to communicate is your own).
Since voicing the claim that marketing is important often leads to discussions with people who hate marketing of any kind, I added an appendix with an example which illustrates nicely what happens when you don’t do any PR - and what happens if you do PR of the wrong kind.
If you’re pressed for time and want the really short form, just jump to the questionnaire.
I just needed to tweak my Emacs org-mode to beamer-latex export to embed images into a figure environment (not wrapfigure!). After lots of googling and documentation reading I decided to bite the bullet and just read the source. Which proved to be much easier than I had expected.
This tutorial requires at least org-mode 8.0 (before that you had to use hacks to get figure without a caption). It is only tested for org-mode 8.0.2: The code you see when you read the source might look different in other versions.
I just decided to give a default answer when I get some email from people asking me to connect to them on some new unfree service:
You asked me to connect with you on some unfree service. If you still want that, just use a status.net-server. Those are federated, so you can use a number of different providers and still be connected to everyone on any other server.
I recently started really learning Fortran (as opposed to just dabbling with existing code until it did what I wanted it to).
Here I document the surprises I found along the way.
As reference: I come from Python, C++ and Lisp, and I actually started to like Fortran while learning it. So the horror-stories I heard while studying were mostly proven wrong. I uploaded the complete code as base60-surprises.f90.
Timezones of most active TCCON stations in UTC+x (without daylight saving time (DST). Because I needed it and could not find a simple list quickly.
darwin: 9, # Timezones2008 says 9 1/2???
Plotting global equal area maps with python, matplotlib/pylab and Basemap.
→ a comment to You call it privacy invasion, I don't from Flameeyes.
What you state is a strong version of the “I’ve got nothing to hide” argument. If you’re interested in a thorough debunking, there is a very good article in the chronicle about that: Why Privacy Matters even if you have nothing to hide.
It’s always a great feeling to see a flattr - Thank you for your support!
You can find new free works for you enjoyment on draketo.de (infrequent and bursty) and 1w6.org (currently weekly but mostly in German).
Es ist ein tolles Gefühl, geflattrd zu werden - Danke für eure Unterstützung!
If you came here searching for a way to set the username in Mercurial: just edit
username = YOURNAME <EMAIL>
If that file does not exist, simply create it.
Update (2013-04-18): In #mercurial @ irc.freenode.net there were discussions yesterday for improving the help output if you do not have your username setup, yet.
I recently tried contributing to a new project again, and I was quite surprised which hurdles can be in your way, when you did not setup your environment, yet.
So I decided to put together a small test for the basic workflow: Cloning a project, doing and testing a change and pushing it back.
I did that for Git and Mercurial, because both break at different points.
I’ll express the basic usecase in Subversion:
You can also replace the request for commit rights with creating a patch and sending it to a mailing list. But let’s take the easiest case of a new contributor who is directly welcomed into the project as trusted committer.
A slightly more advanced workflow adds testing in a clean tree. In Subversion it looks almost like the simple commit:
I have been tweaking my emacs configuration for years, now, and I added quite some cruft. But while searching for the right way to work, I also found some gems which I direly miss in pristine emacs.
This file is about those gems.
Babcore is strongly related to Prelude. Actually it is exactly like prelude, just with the stuff I consider essential.
But before we start, there is one crucial piece of advice which everyone who uses Emacs should know:
Hold control and hit g.
That gets you out of almost any situation. If anything goes wrong, just hit C-g repeatedly till the problem is gone - or you cooled off far enough to realize that a no-op is the best way to react.
To repeat: If anything goes wrong, just hit C-g.
I love the syntax of Python, but crave the simplicity and power of Lisp.
display "Hello World!" ↦ (display "Hello World!")
define : hello-world ↦ (define (hello-world) display "Hello World!" ↦ (display "Hello World!"))
hg clone http://bitbucket.org/ArneBab/wisp
Update (2013-09-13): Wisp now has a REPL! Thanks go to GNU Guile and especially Mark Weaver, who guided me through the process (along with nalaginrut who answered my first clueless questions…).
To test the REPL, get the current code snapshot, unpack it, run
./bootstrap.sh, start guile with
$ guile -L .(requires guile 2.x) and enter
Example usage:then hit enter thrice.
display "Hello World!\n"
Voilà, you have wisp at the REPL!
Caveeat: the wisp-parser is still experimental and contains known bugs. Use it for testing, but please do not rely on it for important stuff, yet.
Update (2013-09-10): wisp-guile.w can now parse itself! Bootstrapping: The magical feeling of seeing a language (dialect) grow up to live by itself:
python3 wisp.py wisp-guile.w > 1 && guile 1 wisp-guile.w > 2 && guile 2 wisp-guile.w > 3 && diff 2 3. Starting today, wisp is implemented in wisp.
Update (2013-08-08): Wisp 0.3.1 released (Changelog).
I recently started looking into Autotools, to make it easier to run my code on multiple platforms.
Naturally you can use cmake or scons or waf or ninja or tup, all of which are interesting in there own respect. But none of them has seen the amount of testing which went into autotools, and none of them have the amount of tweaks needed to support about every system under the sun. And I recently found pyconfigure which allows using autotools with python and offers detection of library features.
TCO: Reducing the algorithmic complexity of recursion.
Debug build: Add overhead to a program to trace errors.
Debug without TCO: Obliterate any possibility of fixing recursion bugs.
“Never develop with optimizations which the debug mode of the compiler of the future maintainer of your code does not use.”°
Tail Call Optimization (TCO) makes this
def foo(n): print(n) return foo(n+1)
behave like this
def foo(n): print(n) return n+1
n = 1 while True: n = foo(n)
Currently I rework my code extensively before I push it into upstream SVN. Some of that is inconvenient and it would be nicer to have easy to use refactoring tools.
hg evolve might offer that.
This test uses the mutable-hg extension in revision c70a1091e0d8 (24 changesets after 2.1.0). It will likely be obsolete, soon, since mutable-hg is currently moved into Mercurial core by Pierre-Yves David, its main developer. I hope it will be useful for you, to assess the future possibilities of Mercurial today. This is not (only) a pun on “obsolete”, the functionality at the core of evolve which allows safe, collaborative history rewriting ☺
NC covered works trick people into investing in a dead end
Free licensing lowers the barrier of entry to creating cultural works, which unlocks a dynamic where people can realize their ideas much easier - and where culture can actually live, creating memes, adjusting them to new situations and using new approaches with old topics.
But for that to really take off, people have to be able to make a living from their creations - which build on other works.
Debunking the myth that you can increase the performance of creative workers with carrot and stick.
Update: I sent this text to the gnu maintainers, and after the original article had been offline for several years, they now managed to convince Alfie Kohn to allow them to distribute the article again. So Studies Find Reward Often No Motivator is finally online again! → gnu.org/p/motivation.html
My text might not have been included on the GNU websites, but it fullfilled its purpose - though in a different way than I had expected.
Update: I got the feedback that some messages in this article are still unclear. It should not implicate, that “in order to increase motivation in the free software world people need to be offered a high income and a long term contract”. Paying a good income in a long term contract is a way to avoid the harmful effect payment can have on performance while enabling someone to work full-time on the project. An empirical study found, that the source and intensity of motivation of free software developers does not differ significantly between people who work for hire and people who work without payment, so many companies employing free software developers seem to do it right (or only the companies who do it right can keep their free software programmers).1
A few months ago, the GNU project had to withdraw its article on motivation and monetary reward, because its author did not allow them to spread it anymore. So I recreated its core - with references to solid research.
For creative tasks, the quality of performance strongly correllates with intrinsic motivation: Being interested in the task itself.
This article will only talk about that.
The main factors which are commonly associated with intrinsic motivation are:
To make it short: Anything which diverts the focus from the task at hand towards some external matter (either positive or negative) reduces the intrinsic motivation and that in turn reduces work performance.
If you want to help people perform well, make sure that they don’t have to worry about other stuff besides their work and give them positive verbal feedback about the work they do.
Note: In the paper »Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects« from 2005, Karim R. Lakhani and Robert G Wolf showed empirically that the payment people get to work in free software projects has no detrimental effect on their intrinsic motivation. In their sample 40% of the developers were paid for their work on free software projects and their intrinsic motivation was as high as the motivation of unpaid developers.
We find […], that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver. The source and intensity of motivation of free software developers does not differ significantly between people who work for hire and people who work without payment. From Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects by Karim R. Lakhani* and Robert G Wolf** from the * MIT Sloan School of Management | The Boston Consulting Group and ** The Boston Consulting Group. ↩
The new Humble Indie Bundle is no longer free, indie, cross-plattform or user-respecting.
→ comment on Slashdot concerning Unexpected methods to promote freedom?
Was it really Apple who ended DRM? Would they have done so without the protests and evangelizing against DRM? Without protesters in front of Apple Stores? And without the many people telling their friends to just not accept DRM?
That “preaching” created a situation where Apple could reap monetary gain from doing the right thing.
It does not do auto-scaling of embedded images, as far as I know, but the use case of screenshots can be done with a simple function (add this to your ~/.emacs or ~/.emacs.d/init.el):
Matthew Gregg: @marjoleink "way of life" thing again, but if you can invest some time, org-mode is a really powerful note keeping environment. → Marjolein Katsma: @mcg I'm sure it is - but seriously: can you embed a diagram2 or screenshot, scale it, and link it to itself? ↩
For diagrams, you can just insert a link to the image file without description, then org-mode can show it inline. To get an even nicer user-experience (plain text diagrams or ascii-art), you can use inline code via org-babel using graphviz (dot) or ditaa - the latter is used for the diagrams in my complete Mercurial branching strategy. ↩
I recently needed to send an email to many people1.
Putting all of them into the BCC field did not work (mail rejected by provider) and when I split it into 2 emails, many did not see my mail because it was flagged as potential spam (they were not in the To-Field)2.
I did not want to put them all into the To-Field, because that would have spread their email-addresses around, which many would not want3.
You simply write the email as usual via
wl-draft, then put all email addresses you want write to into a buffer and call
M-x wl-draft-send-to-multiple-receivers-from-buffer. It asks you about the buffer with email addresses, then shows you all addresses and asks for confirmation.
Then it sends one email after the other, with a randomized wait of 0-10 seconds between messages to avoid flagging as spam.
If you want to use it, just add the following to your .emacs:
(defun wl-draft-clean-mail-address (address) (replace-regexp-in-string "," "" address))
(defun wl-draft-send-to-multiple-receivers (addresses) (loop for address in addresses do (progn (wl-user-agent-insert-header "To" (wl-draft-clean-mail-address address)) (let ((wl-interactive-send nil)) (wl-draft-send)) (sleep-for (random 10)))))
(defun wl-draft-send-to-multiple-receivers-from-buffer (&optional addresses-buffer-name) "Send a mail to multiple recipients - one recipient at a time" (interactive "BBuffer with one address per line") (let ((addresses nil)) (with-current-buffer addresses-buffer-name (setq addresses (split-string (buffer-string) "\n"))) (if (y-or-n-p (concat "Send this mail to " (mapconcat 'identity addresses ", "))) (wl-draft-send-to-multiple-receivers addresses))))
The email was about the birth of my second child, and I wanted to inform all people I care about (of whom I have the email address), which amounted to 220 recipients. ↩
Naturally this technique could be used for real spamming, but to be frank: People who send spam won’t need it. They will already have much more sophisticated methods. This little trick just reduces the inconvenience brought upon us by the measures which are necessary due to spam. Otherwise I could just send a mail with 1000 receivers in the BCC field - which is how it should be. ↩
Sure, there are also template mails and all such, but learning to use these would consume just as much time as extending emacs - and would be much less flexible: Should I need other ways to transform my mails, I’ll be able to just reuse my code. ↩
When you enter the freenet Web of Trust, you first need to get some trust from people by solving captchas. And even when people trust you somehow, you have no way to prove your identity in an automatic way, so you can’t create identities which freenet can label as trusted without manual intervention from your side.
To change this, we can use the Web of Trust used in GnuPG to infer trust relationships between freenet WoT IDs.
Practically that means:
An answer to a reddit-comment by tedemang to the article 1540 Anonymous vs. TrapWire: "We must, at all costs, shut this system down and render it useless".
Also ris is far from human readable.
ris can be reformatted to bibtext, but doing that manually disturbs my workflow when getting references while taking note about a paper in emacs.
I tend to search online for references, often just using google scholar, so when I find a ris reference, the first data I get for the ris-citation is a link.
Emacs is a self-documenting, extensible editor, a development environment and a platform for lisp-programs - for example programs to make programming easier, but also for todo-lists on steroids, reading email, posting to identi.ca, and a host of other stuff (learn lisp).
In Markdown-mode it looks like this:
This is a complete branching strategy for Mercurial with optional adaptions for maintaining multiple releases1. It shows you all the actions you may need to take, except for those already described in the guide Mercurial in workflows.
For examples it uses the command-line UI, but it can easily be used with graphical Mercurial interfaces like TortoiseHG.
A simpler workflow for groups who need no separate stable branch is described in Feature seperation via named branches.
Firstoff, any model to be used by people should consist of simple, consistent rules. Programming is complex enough without having to worry about elaborate branching directives. Therefore this model boils down to 3 simple rules:
(1) you do all the work on
default2 - except for hotfixes.
(3) you can use arbitrary feature-branches5, as long as you don’t call them
stable. They always start at default (since you do all the work on default).
To visualize the structure, here’s a 3-tiered diagram. To the left are the actions of developers (commits and feature branches) and in the center the tasks for maintainers (release and hotfix). The users to the right just use the stable branch.6
Now we can look at all the actions you will ever need to do in this model:7
(edit); hg ci -m "message"
continue development after a release:
hg update; (edit); hg ci -m "message"
start a larger feature:
hg branch feature-x; (edit); hg ci -m "message"
continue with the feature:
hg update feature-x; (edit); hg ci -m "message"
merge the feature:
hg update default; hg merge feature-x; hg ci -m "merged feature x into default"
close and merge the feature when you are done:
hg update feature-x; hg ci --close-branch -m "finished feature x"; hg update default; hg merge feature-x; hg ci -m "merged finished feature x into default"
Tasks for Maintainers
create the repo:
hg init reponame; cd reponame
(edit); hg ci -m "message"
create the stable branch and do the first release:
hg branch stable; hg tag tagname; hg up default; hg merge stable; hg ci -m "merge stable into default: ready for more development"
apply a hotfix8:
hg up stable; (edit); hg ci -m "message"; hg up default; hg merge stable; hg ci -m "merge stable into default: ready for more development"
do a release9:
hg up stable; hg merge default; hg ci -m "merged default into stable for release" ; hg tag tagname; hg up default ; hg merge stable ; hg ci -m "merged stable into default: ready for more development"
default is the default branch. That’s the named branch you use when you don’t explicitely set a branch. Its alias is the empty string, so if no branch is shown in the log (
hg log), you’re on the default branch. Thanks to John for asking! ↩
If you want to release the changes from
default in smaller chunks, you can also graft specific changes into a release preparation branch and merge that instead of directly merging default into stable. This can be useful to get real-life testing of the distinct parts. For details see the extension Graft changes into micro-releases. ↩
Maintainers are those who do releases, while they do a release. At any other time, they follow the same patterns as everyone else. If the release tasks seem a bit long, keep in mind that you only need them when you do the release. Their goal is to make regular development as easy as possible, so you can tell your non-releasing colleagues “just work on default and everything will be fine”. ↩
This model does not use bookmarks, because they don’t offer benefits which outweight the cost of introducing another concept, and because named branches for feature branches offer the advantage, that new programmers never get the code from a feature-branch when they clone the repository. For local work and small features, bookmarks can be used quite well, though, and since this model does not define their use, it also does not limit it.
Additionally bookmarks could be useful for feature branches, if you use many of them (in that case reusing names is a real danger and not just a rare annoyance, and if you have a recent Mercurial, you can use the
@ bookmark to signify the entry point for new clones) or if you use release branches:
“What are people working on right now?” →
“Which lines of development do we have in the project?” →
hg branches ↩
Those users who want external verification can restrict themselves to the tagged releases - potentially GPG signed by trusted 3rd-party reviewers. GPG signatures are treated like hotfixes: reviewers sign on stable (via
hg sign without options) and merge into default. Signing directly on stable reduces the possibility of signing the wrong revision. ↩
hg pull and
hg push to transfer changes and
hg merge when you have multiple heads on one branch are implied in the actions: you can use any kind of repository structure and synchronization scheme. The practical actions only assume that you synchronize your repositories with the other contributors at some point. ↩
Here a hotfix is defined as a fix which must be applied quickly out-of-order, for example to fix a security hole. It prompts a bugfix-release which only contains already stable and tested changes plus the hotfix. ↩
If your project needs a certain release preparation phase (like translations), then you can simply assign a task branch. Instead of merging to stable, you merge to the task branch, and once the task is done, you merge the task branch to stable. An Example: Assume that you need to update translations before you release anything. (next part: init: you only need this once) When you want to do the first release which needs to be translated, you update to the revision from which you want to make the release and create the “translation” branch:
hg update default; hg branch translation; hg commit -m "prepared the translation branch". All translators now update to the translation branch and do the translations. Then you merge it into stable:
hg update stable; hg merge translation; hg ci -m "merged translated source for release". After the release you merge stable back into default as usual. (regular releases) If you want to start translating the next time, you just merge the revision to release into the translation branch:
hg update translation; hg merge default; hg commit -m "prepared translation branch". Afterwards you merge “translation” into stable and proceed as usual. ↩
If you want to adapt the model to multiple very distinct releases, simply add multiple release-branches (i.e.
hg graft the changes you want to use from default or stable into the releases and merge the releases into stable to ensure that the relationship of their changes to current changes is clear, recorded and will be applied automatically by Mercurial in future merges11. If you use multiple tagged releases, you need to merge the releases into each other in order - starting from the oldest and finishing by merging the most recent one into stable - to record the same information as with release branches. Additionally it is considered impolite to other developers to keep multiple heads in one branch, because with multiple heads other developers do not know the canonical tip of the branch which they should use to make their changes - or in case of stable, which head they should merge to for preparing the next release. That’s why you are likely better off creating a branch per release, if you want to maintain many very different releases for a long time. If you only use tags on stable for releases, you need one merge per maintained release to create a bugfix version of one old release. By adding release branches, you reduce that overhead to one single merge to stable per affected release by stating clearly, that changes to old versions should never affect new versions, except if those changes are explicitely merged into the new versions. If the bugfix affects all releases, release branches require two times as many actions as tagged releases, though: You need to graft the bugfix into every release and merge the release into stable.12 ↩
If for example you want to ignore that change to an old release for new releases, you simply merge the old release into stable and use
hg revert --all -r stable before committing the merge. ↩
A rule of thumb for deciding between tagged releases and release branches is: If you only have a few releases you maintain at the same time, use tagged releases. If you expect that most bugfixes will apply to all releases, starting with some old release, just use tagged releases. If bugfixes will only apply to one release and the current development, use tagged releases and merge hotfixes only to stable. If most bugfixes will only apply to one release and not to the current development, use release branches. ↩
In the mercurial list Stanimir Stamenkov asked how to get rid of intermediate merges in the log to simplify reading the history (and to not care about missing some of the details).
Update: Since Mercurial 2.4 you can simply use
hg log -Gr "branchpoint()"
I did some tests for that and I think the nicest representation I found is this:
hg log -Gr "(all() - merge()) or head()"
This article shows examples for this.
this just happened to me in the #freenet IRC channel at freenode.net (somewhat edited):
toad_1: what can freenet do well already? [18:38]
toad alias Matthew Toseland is the main developer of freenet. He tends to see more of the remaining challenges and fewer of the achievements than me - which is a pretty good trait for someone who builds a system to which we might have to entrust our basic right of free speech if the worls goes on like this. From a PR perspective it is a pretty horrible trait, though, because he tends to forget to tell people what freenet can already do well :) ↩
I wrote some recipes for creating the kinds of slides I need with emacs org-mode export to beamer latex.
Update: Read ox-beamer to see how to adapt this to work with the new export engine in org-mode 0.8.
Below is an html export of the org-mode file. Naturally it does not look as impressive as the real slides, but it captures all the sources, so I think it has some value.
Note: To be able to use the simple block-creation commands, you need to add #+startup: beamer to the header of your file or explicitely activate org-beamer with
I just read your article on per use payments.
I think there are two serious flaws in per use payments:
As you stated correctly, I define myself partly through the media I "consume".
This does mean, that I want to have the assurance, that I can watch a great movie again a few years in the future.
Imagine this scenario:
The probes project is a google summer of code project of Steve Dougherty intended to optimize the network structure of freenet. Here I will give the background of his project very briefly: