The Contribution Manual

Talk to the maintainer first, you dumb faggot.

No, nobody is mandated, but it would be nice if more people cooperated. Just because you don't have to doesn't mean you shouldn't, just like just because you don't have to write unit tests doesn't mean you shouldn't.

Serious proprietary software does have those documents, and not so serious proprietary software with smaller teams has a guy personally explaining to you how shit works for a week before you are expected to contribute on your own.

You are missing the point. Yes, what we have satisfies the bare minimums, but we can go beyond and we can do better.

all you need to do is code better, the purpose of all these projects

t. nogrammer

It might be, and this is just a suggesstion here, but maybe your average coder thinks that in-depth documentation should be up to others, and not them.

Not him, but my grammar comprehension sucks, I think.

suck my white cis benis you absolute unit

I think a lot of programmers are too intelligent for their own good. They can write a several thousand line of code source file with no comments and they will know where everything is. I'm a brainlet, which is why I always try to split things up and have docstrings even for functions which are not part of a module's public interface.

Is this how a brainlet adds a new feature?
You should just use tools to automate finding the place where you need to add the new feature. Look at something similar to what you are adding and then copy that as a basis for your addition.
There is no need to understand every line of code.

Is this how a brainlet finds the cure to cancer?
You should just use tools to automate finding the place where you need to investigate the cure. Look at a similar disease to what you are investigating and then copy the drug used to treat it as a basis for your cure.
There is no need to understand every type of cancer ever.

Reposting because I think my previous one got eaten.

Good lord finally a decent post on Zig Forums (only took linux getting fucking comped) and all these dipshit 12-year-old no-coders are out in force...

I struggle with the same problems . I've wanted to help contribute to code-bases but the vast majority, let alone having any form of documentation/rhyme or reason to file organization, often don't even HAVE a visible main file. There are even cases where a library I wanted to use was so poorly documented that I wound up having to reimplement it myself from scratch just from the theory of it because it would take even longer to learn their particular brand of autism, or completely kludge up my own code.

Anyone that tells you that you are wrong here is either autistic, trolling, or has never had a project that grew to more than 5 files of code. We don't really need to make writing documentation easier, rather what needs to be done is to spread awareness of existing tools which can already do this such as pandoc, doxygen, and methods of using code-gen techniques and sed to generate docs. The trick here is that we need to work on providing more resources on when it is time to get dirty and actually WRITE the documentation; HOW to write it; What things to cover, etc...

For example, what precisely constitutes a good HACKING.txt file? What elements should it contain? Why? In my case, I tend to to keep code-level documentation (why did I do X, for example) as comments in my code, with theory-level documentation (how does something actually work) in a separate file, but I can't help feeling as though it is lacking, even despite me using (admittedly intelligent) no-coders as test-readers for clarity. Admittedly, I am a solo-dev, so maintaining clarity in docs for me is not as difficult as I imagine it would be for a team.

For my own thoughts here - I personally think a HACKING.txt file should be more like an introductory info dump. It would serve as essentially a table of contents with a bit of extra high-level info in it that links(or something like "for more info, view doc/blah/clockwork_stupidity.txt") to the more verbose technical write-ups if necessary. The key here is to write even your technical info in common english. There's no need to masturbate with a dictionary if plain, simple english will suffice to convey an idea. Will this allow retards to understand your code? Yeah, it will, but that is kind of the point of documentation last time I checked - to free yourself from answering questions and be able to focus on writing more code.

This leads us to the problem: most modern devs are retarded lazy fucks. They won't write documentation beyond a shitty raw doxygen dump. They will act like "read the source" is even a remotely viable stance on documentation when their code grows beyond 2-3 files or is written in nothing but hacky header retardation and C++ template stupidity or is full-on pajeet code. They will even tell you to use an IDE as they demonstrate they are no better than the average pajeet (sometimes even terrifyingly worse - I've actually bumped into competant pajeets).

..Except when there's that one tiny fucking thing that depends on what you are tweaking and causes either unintended breakage for another feature (yes, lots of things are written this poorly) or even can cause a massive security risk. Congrats on writing pajeet code if you do this.

Completely agreed. They don't understand that the true measure of intellect is not in how many words one can string together, but how well one can convey their thoughts with less.

none of this matters if dont provide work, code
you can write the greatest esse debating this shit, its irrelevant
nobody cares
more brown people isnt going to make your code better

That was a long way to say "FOSS docs are shit". If you ask me, this can't be fixed unless the developers start to simplify and try to set things in stone, for which you'd have to nuke easily half of all programmers out of the field. Right now, there's a cancerous zeitgeist of constant change for the sake of change. The idea that a project which doesn't constantly add pointless extra "features" should not be used because it is "dead" is extremely widespread, even though it's horribly wrong. It provides nice job security for the people making these changes though.

The only thing worse than no documentation is wrong documentation, and the move fast and break things people can't be arsed to update documentation either. Who wants to write documentation for such a project, and for free at that?

This isn't being smart, it's a mere matter of time spent on writing the thing. Creating something simple and understandable is the difficult part.

No, FOSS documentation doesn't really suck, or at least in general. Documentation on how to use FOSS programs is abundant and very decent most of the time, and documentation on how to use libraries (read: doxygen dumps, javadocs, etc) are decent sometimes. Problem is these types of docs are good to build stuff upon what the software offers, but they are misguided for modifying anything related to what's already there. I am going to assume the FOSS community copied the kind of manuals that are offered with proprietary software, without realizing the FOSS usecases are wider and require something more specific and exclusive to FOSS.

In my opinion, programs should first be designed thinking about features, then grouping said features in subsystems, then document a high level overview of those subsystems so contributors can read this stuff and understand at first glance the way the program is structured, and then decide to go straight to the thing he wants to work in.

But that's the kind of documentation we are talking about.
This seems like a stretch, what do you base that on? The part about subsystems looks sound to me.

Proprietary commercial software often comes with user manuals in case they are end-user programs, and extensive tutorials on how to do stuff, which we kind of already have. The user doesn't need to know anything more because they are not going to be able to do with it anything but what the original devs intend to, so there is no need to make public any more manuals than user manuals.

Proprietary commercial libraries often come with doxygen docs or equivalent, maybe some tutorials on how to use the library, which we already have as well. This is because all the end programmer needs to know is the API, and not how much of a spaghetti the code is behind.

However, FOSS contemplates the possibility of modifying the program as well. This is something exclusive to FOSS and it has always been, so there is no equivalent proprietary manual for this aspect of the program. But we can see here that programs with excellent end user manuals, like Krita, have really poor HACKING files, and we should be thankful they even have a HACKING file. It seems as if the community never cared about developing a deeper method of documentation, the contribution manuals we are talking about in this thread.

I see it the same way. The HACKING file should provide a high-level overview of the project, the knowledge needed (algorithms and data structure) and serve as a guide on where to find what (if the project is so large that it isn't obvious). When someone want to change the project, the HACKING file should serve as the first instruction.

In addition there should be a CONTRIBUTE file with instructions as to how to contribute (code style, scope of the project, commit style, etc.) and an INSTALL file with installation instructions. If the instructions are only a paragraph or two they can fit inside the README file as well. I hate it when an author thinks he needs to cram everything inside the README.

I see writing documentation the same way as I see writing tests. Every time you introduce a new feature or fix a bug you should add test cases to guard it. No one likes testing, but it's a matter of discipline. The same discipline should also apply to writing documentation.

Writing documentation can also help your program: if you are having trouble explaining something, then chances are it's shit. I have found myself writing code thinking it's pretty good, only to find it horrible to use when it actually came to putting into words how to use it.

No, not really. FOSS documentation is usally pretty good. GNU projects have huge book-sized manuals covering everything in depth. Usually that documentation is for reference though, not something that's suitable as an introductory guide. Reading the manual for GCC assumes that you already know how to use it, and that you are looking up specific topics.

Can you fags link the repos and what you your patches would do?

Would be hilarious if they suddenly got a few hundred PRs.

Agreed completely. I didn't even think of the CONTRIBUTING file due to always assuming my code would never so much as be seen, so thanks for adding that.

I realize this may be a bit stupid, cringy, and border-line autistic, but at this point I think just having even a small info dump regarding documentation may not be uncalled for given that there seems to be a serious lack of understanding regarding it. Obviously a lot of devs are lazy as shit, but this might still be useful for future anons that simply don't know how to write decent docs. I know for a long time I was one of those anons at least, and I would have killed for a simple guide. Also it would be nice to have an official Zig Forums guide and actually do something related to tech here for a change rather than watching yet another thread devolve into arguing with the board blackpill or the ol' unix hater back-and-forth spergout (assuming that these two aren't the same damn person).

The list so far for an unofficial Zig Forums guide to not sucking at documentation:
1. CONTRIBUTING - Methods to contribute, how to write commit logs, code style, perhaps some algorithim-related decisions, project scope.
2. HACKING - High-level overview of and index into the more extended documentation for quick reference.
3. README - Keep the readme small and focused on a rough over-view of the project.
4. INSTALL - If installation is at all involved, use this instead of the README for all installation-related info.

I also suggest adopting the GPL's style of providing license info so as to maintain a standardized name.
5. COPYING - License info.

Useful tools for aiding in documentation:
* pandoc (pandoc.org/): Pretty much a swiss-army knife in regards to converting documentation into other formats. Also makes writing manpages easier.
* doxygen (doxygen.nl/): Can generate an API dump from specially formatted comments. I'm not entirely support how many languages this supports.
* GNU Make (gnu.org/software/make/) or alternative: Even if your code is not using Make to compile it is a wonderful tool for when you need
to leverage one of the above and want to automate the process in a faster way than [insert shell here].

Notes on how to write documentation:
* Use plain english unless absolutely necessary to convey a subject.
* Logically partition your documentation - the HACKING file will be your index and overview for all your separate files.
* Don't dump everything into your README unless the info is small enough to not bloat it into more than a page or two at max.
* Always treat writing documentation no different to writing the build system for your project.
* Grow your docs like they are part of your source code.
* Even vague (but correct) notes are better than nothing.

Notes on when to write documentation:
* If your codebase is more than a few files, or consists of code that would not be understandable except to someone who deeply understands the language in question and particularly its nuances (looking at you C++) and entirely relies on code comments
* If you intend to grow your project beyond solo-dev status
* If your code's documentation is trying to convey why you did something rather than why you wrote the code the way you did, it is definitely time.

Notes on when it is fine to not write documentation:
* Hold off on writing up complete documentation for something until you are either certain of it(you know exactly what you are going to do and merely need to write the code to achieve it). Stick to notes and what-not in that case.

Thoughts? Tweaks? Logo?

mmh dat wedgie ass

Signs it's time to write documentations:

I think if the installation is something trivial that can be mentioned in the README. For example Vim plugins that don't do anything out of the ordinary are all installed the same, so one sentence like "Install this plugin the usual way" doesn't really warrant a file of its own. And BTW, it should be assumed that the user of the plugin is intelligent enough to know what "the usual way" is, there is no need to list boilerplate code for five different plugin managers. If there is nothing special about it, don't waste my attention.

I would also suggest to add the following files:

< 6. HISTORY or CHANGELOG
Changelog and stuff, can contain full sentences instead of just cliffnotes if necessary
< 7. Authors
List of contributors, possibly with annotations if necessary

Add Docutils, Sphinx and Texinfo to that list as well.
Yes, make is really handy. Even if the code does not need to be compiled, I find it really handy to have targets like "check" for runnings tests, or "doc" for generating documentation. I also like having a "help" target which prints all the important targets and descriptions to the shell.

Added suggestions, along with a bit more expansion on various files and breaking up each file into its own explanation rather than a hideous list.

I also added an optional USAGE file since I've seen some READMEs get horrifyingly bloated from massive tutorials on how to use the software, thoughts?

The unofficial Zig Forums guide to not sucking at documentation:

[Part 1 - Generally recommended files and when/why/how to use them]
README:
Consider your README as a 50-mile-overview of the project. It should contain a basic map to your provided documentation and, provided it won't get bloated beyond a page or two at most, you can condense some of the optional files into it, such as INSTALL or USAGE. There is no excuse NOT to have this file unless you are making a one-off script or some kind of toy.

INSTALL:
If your project's installation procedure is simple (`make -j; make test; make install`), then including it in the README is okay. If however it takes more than five or so lines to explain the procedure, or has many options or alternative steps (ex: some projects let you decide whether to use a bundled simplified method of doing something or one from a special library if installed), then it should be placed in the INSTALL file along with the rest of the information. Regardless you shouldn't duplicate information unless it is tied-into the build and/or installation of your project. As an example, take Vim plugins. You don't need to explain for the 835 billionth-time how to install a plugin for 3+ different plugin-managers - the plugin-managers themselves explain how to do this. Now to contrast - let's say your plugin is something like YouCompleteMe, which has an extra step in which you must compile part of it. That would be a good case to repeat some of the info if a given popular plugin-manager requires extra steps.

CONTRIBUTING:
This file should contain instructions on things such as code formatting, commit message formatting(if applicable), doc formatting, and other related subjects. Another good use for this is to explain the scope of your project (X is doing Y but that doesn't mean it is also trying to do Z), as well as define how you want your bug reports to be done.

HACKING:
This file should generally be used as an index to your documentation. It should contain short summaries of your more verbose docs, as well as link to relevant files/external docs as needed. This is a good place to also convey the structure of your project, why it is that way, and perhaps also note previous attempts and why they were altered, in case that information becomes useful in the future should new devs join.

COPYING or LICENSE:
This file should contain your license info, even if it is simply public domain. This is pretty much mandatory if you write anything beyond a one-off script or toy.

HISTORY or CHANGELOG:
This file will contain any and all changes to your code-base. This file can be optional if you are using a VCS that provides history logs, though even then it could be used for important updates such as milestones.

AUTHORS:
This file would contain a list of authors, and, should they be willing, contact information for them such as an email address. Unless your project is extremely visible, such as being ffmpeg or something similarly used, you can probably fore-go the contact info and just rely on bug reports as documented in your CONTRIBUTING file.

USAGE:
If the usage of your project is not simple enough to convey the nuances via --help, or for some horrifying reason you cannot or will not provide man-pages, this would be where to go into detail of how to use your software. If this is short enough you can generally jam it into the README, as mentioned above, or just forego it completely. It is also good to show examples of complex invocations here, though don't go too over-board with them.

[Part 2 - Notes and tips on documentation]
How to write documentation:
* Use plain english unless absolutely necessary to convey a subject.
* Logically partition your documentation - the HACKING file will be your index and overview for all your separate files.
* Don't dump everything into your README unless the info is small enough to not bloat it into more than a page or two at max.
* Always treat writing documentation no different to writing the build system for your project.
* Grow your docs like they are part of your source code.
* Even vague (but correct) notes are better than nothing.

When to write documentation:
* If your codebase is more than a few files, your src folder is actually a fully fledged tree with folders inside folders, or consists of code that would not be understandable except to someone who deeply understands the language in question and particularly its nuances (looking at you C++) and entirely relies on code comments
* If you intend to grow your project beyond solo-dev status or intend to eventually cease maintaining your project, leaving it up to the community to continue it.
* If your code's documentation is trying to convey why you did something rather than why you wrote the code the way you did, it is definitely time.

When it is fine to not write documentation:
* Hold off on writing up complete documentation for something until you are either certain of it(you know exactly what you are going to do and merely need to write the code to achieve it). Stick to notes and what-not in that case.

[Part 3 - Useful tools for aiding in documentation]
For processing intermediate text (markdown, asciidoc, etc) into other forms (html, epub, pdf, etc):
* pandoc (pandoc.org/)
* docutils (docutils.sourceforge.net/)
* texlive (tug.org/texlive/)

For creating documentation from your source code comments as well as external files:
* doxygen (doxygen.nl/)
* sphinx (tug.org/texlive/)

Alternatives to shell scripts for driving doc generation:
* GNU Make (gnu.org/software/make/) or alternative: Even if your code is not using Make to compile it is a wonderful tool for when you need to leverage one of the above and want to automate the process in a faster way than [insert shell here].

Pretty good. I like that you decided to do something actually useful instead of all of us usually just bitching. Good for you.

Why include this one? TeX Live is just a distribution of TeX, not a system on its own, so it would be more appropriate to just list TeX or LaTeX to keep it more general.

But more to the point, TeX can only generate printed output (and PDF of course), no HTML. Did you mean Texinfo?
gnu.org/software/texinfo/

Texinfo started out as just a TeX library, but it has since evolved into its own project and can produce a variety of outputs, including HTML, PDF, and Info. Info can be read in the shell, in Emacs or in Vim directly. Texinfo is the canoncial documentation system for GNU projects and is used to write their book-sized manuals.

A million times this. If you don't communicate your intentions before taking on a job, don't get angry if your labour goes unapreciated.

Pic unrelated.

Attached: 1516546872537.jpg (480x480, 32.37K)

Attached: 15cf84ce2e86c468cdf0edda619954e7.gif (270x214, 1.41M)

I have another one:
What needs to be done, can be a list of short cliffnotes of things not to forget, or full sentences describing the future direction of the projects. Things like outstanding refactoring jobs, new features to add or what direction to take the project into.

I am not quite sure about this one; it should of course not list every single bug from the bug tracket, but it should list longstanding bugs that are hard to root out, along with discussion about the nature of the bug. As I said, I am not sure if such a file is really needed, but manpages often have a "bugs" section.

If you start doing major changes to someone else's project, then you should better discuss it first with current contributors. Only minor contributions, bug fixes or pure additions (without being more lines than the current codebase) can come out of blue.

Or just follow the literate programming paradigm.

I tried looking into it the other day, but my instincts tell me wrapping code in a bunch of macros is going to confuse outsiders more, not less.

Also, on a less charitable note, the whole literate programming thing (as described by Donald Knuth without modern reinterpretations) seemed like just a way to turn code into an academic papers.

Logically impossible.

I will bring up that time the GIMP team rejected a small fix that allowed docking panels to the bottom of the window because then users could, on their own, make the user interface more Photoshop-like.

Are there any good resources to learn how to write documentation?

Meant: without the added lines being more than current codebase.

C isn't a good language for programming in the large, duh. The only way to use someone else's code without fucking around with irrelevant bullshit is if it's already compiled into a library by your distro (using some special snowflake compilation process involving autotools).
What you want is something like SML (the only well known language that really has enough support for progrmaming in the large) and with UUIDs for all identifers (for types, functions, values, modules (as in ML modules), etc) and a code browser that automatically displays some human provided names instead of the UUIDs. Also each identifier is signed by whoever coded it. If I code some function, I press the publish button and boom I get a link to the function name I can share with people and they are automatically assured it's created by me using cryptographic signing. There also must be no build system. For anything that needs to be fast you can simply program it in assembly. If you want something like a video game that needs to have giant pieces of fast code, you can go use some homo OS like Windows or Linux.
Documenting code (as in adding comments and maybe external READMEs) is just a meme. Lack of documentation is almost never the bottleneck. If I want to hack something in while being an idiot and not understanding any of the surrounding code or context, I can just grep for a string related to what I'm trying to do and it will work 99% of the time to find me the place I need to edit. If I implement Tarjan's dominator tree algorithm, I will link to the paper and maybe have a few comments if I feel it's necessary. What you _should_ be doing is adding semi-formal documentation to every function, type, and value as needed (e.g Javadoc, Doxygen, Haddock). This documentation process is a basic part of the language and shouldn't need a build process to view. Your code browser/editor should show the documentation of everything even whatever you're working on. The way it's done with Javadoc, Haddock, etc is retarded.

I would ordinarily ignore this bait but I'll bite a little so as to help others that actually might want to learn.
1. You CAN use other peoples code without existing libraries by adding the source files to your build script(if required by your language) and adding the relevant paths to your compile phase(how the fuck else would it know where to look for things? Even languages that don't have this still use environment variables or even worse hard-code this shit). Also virtually nobody uses autotools anymore. The autohell meme exists for a good reason. Look into cmake, meson, or even just plain make faggot.
2. You don't absolutely need a build script unless the language in question requires multiple operations (even C doesn't actually need one. It just makes shit faster to rebuild and stupidly easier because you are applying code-gen techniques to generate a command-line).
3. In academic code, yes you don't need speed. In code that actually is expected to do anything useful for an end user, you do.
4. Okay, without studying existing instructions or relevant documentation for anything, build me a working nuclear reactor and demonstrate it in action. You can't use existing things either, you have to start naked in a field, because remember you can't re-use other people's code, as you said above. You have to forge the metal yourself. The ore will be provided for you as you did okay libraries, but they will not have decent purities because as you said, these are special snowflake OS like linux and windows, and fairly most of the libs in repos do tend to have a strange hodge-podge of features toggled. You have to make everything yourself, but I'll let you at least use fire because as an element itself that certainly comes close to what ASM sort of is for computers. Can you kind of see why you are so horrifyingly wrong regarding documentation now?
5. You are assuming that the build process needs to be necessary to view the docs that have been discussed in this thread. The only build that would even be happening here is translating existing HUMAN READABLE documentation into something like html or an ebook-format like epub or pdf. Other than that you would simply be, again, applying code generation techniques to generate some of your docs, such as a doxygen API dump. This isn't something that can't easily be done by hand, but this isn't the fucking stone ages - we have tools like grep now. We have globs and regex. We have sed. We don't NEED to do this by hand any more.
6. IDEs are for two kinds of people. First are pajeets/hipster retard webdevs. Second are people who have to maintain a MASSIVE (think > 100 files, like a kernel) or extremely complex code-base, both of which also along with tons of other people(even then it is optional). They can definitely assist someone, but are power tools. If I handed you a belt sander you wouldn't really be able to do fine detail work with it, now would you?

The reason I added texlive was because suggested it. I've honestly never used any form of TeX and just about everything I did use in the past was replaced with pandoc driven by makefiles. I'll switch it to TeX/LaTeX instead, my bad. Thanks for clarifying this.

Actually in all honesty yeah, I should have also included what said. Perhaps a new "Contributing to existing projects" part is in order.

TODO I can definitely get behind, BUGS.. I can see where this would be useful if one was not using a VCS with commit messages or was finished working on the project. Another good case would be to bundle it with release tarballs I guess. I'll add a section for both regardless.

I've been developing for over a decade and I've only just now heard of this. It definitely sounds interesting, but without actually trying it out I can't agree on whether it is superior or not to the methods outlined in this thread. I also somewhat agree with here, it sounds like it really is just for academic bloat, with the side-effect of producing a coherent structure - or at least it sounds like it aims to be coherent. Oldfag autists sometimes seem to vary wildly from newfag autists like most if not all of us in this thread with what is and is not coherent. Obviously, do as you will. I'll make a note of this paradigm somewhere in the guide.

That's what I'm trying to create by making this guide with support by the anons in this thread. If you have any questions definitely ask them and I'll try to answer as best as I can. Honestly everything that I've contributed to this is just what I've seen in the field complimented with with what I've found to work with my own projects, with things that aren't really viable re-worked or stripped out completely.

Rather than reposting the WIP guide here and eating up 3ish posts, would it be better to use some kind of pastebin-esque site? Is there one that isn't compromised to shit, or should I just do an anonomous pastebin.com with archive link?

I want to clarify my last bit regarding IDEs. The trick behind them is that they cover up the lower-level bits. A good example for this would be the relationship between C and ASM. You can write C without ever even seeing ASM code, but if you learn ASM you have a better view of the underlying hardware itself. This isn't to say you can't do this without ASM, but it makes it easier. With an IDE you never have to worry about how to invoke the compiler, but due to this, most people never bother to learn how in the first place, which makes things interesting when there's a problem at this level and the dev in question has no clue how to even begin to address the problem. One should grow organically into using IDEs or not at all, is what I'm kind of saying, rather than starting off with one and ignoring the entire underlying environment.

I am both and and you seem to have mistread my earlier post: I mentioned Texinfo, not TeX Live (or any other TeX engine). Honestly, LaTeX should not be used unless you want to write an academic paper involving lots of math. LaTex (or TeX) is better generated from a more high-level format (e.g. using pandoc).

This has been my experience with IDEs, I clicked some stuff and got a nice project with a GUI an everything. Then I wanted to try using a library and I had no idea what to do because all the tutorials on the internet were showing an older version and I couldn't follow them. So I just threw out the IDE and learned how to invoke the C compiler from the terminal. Then I learned about makefiles to automate the steps and I'm pretty comfy in my shell.

Yeah I did misread it, my apologies. I probably found TeX Live and assumed it was TeX itself due to inexperience. I've updated the entry to be "LaTeX (tug.org/)" since tug.org seems to be the correct site from a quick glance.

This werks. paste.debian.net/
Otherwise, unironically use GitHub's gist

I don't want to make a fake github account, so I used the pastebin. Thanks.

Here's the guide as it is currently. I had to reformat it a bit because this pastebin shits itself with lines longer than 80 chars, and I added a bit of info about the target audience so that the most autistic of anons won't sperg out over being told how to write docs, along with a bit of re-working of sentence structure in some places to make it less incoherent.
paste.debian.net/1045116/
archive.is/JxkDa

your parents should have taught you an useful phrase as a child.

Beggers can't be choosers.

wheres the art of OP being fucked?

why the fuck would I ever want to do that

Well, it's a free model you can find in OpenGameArt. It's fully rigged, so you can pose herself tasting a good cock like the French slut she is, if you wish.

I knew I was retarded but I only just now realized the extents. It took me until now to notice that I had the tex url for sphinx.

paste.debian.net/1045729/
archive.is/5NdVK

Write something worthwhile - problem solved. Also, you don't have any examples of this anywhere.

wheres all the porn of the chick in OP?

No one knows.

Any updates OP? You wrote this entire thing out and kind of vanished. You can't do that when you're on to something good, don't you know?

Absolutely don't want your contributions. You don't have the right to access my repository. You think make maintainers would accept my contributions if I started fixing the shortcomings of makefiles? They wouldn't, even though my fixes would make the tool objectively better. Compatibility is important.

Don't like it? Fork.

It would be nice. I try to be nice. However, I don't HAVE to be nice. I'm not getting paid and have absolutely no responsibility for anything I create and I will do things like completely abandoning projects once I no longer care about them. I don't owe people anything and I'm not obligated to come back to a project I haven't committed to in 5 years because someone submitted some PR.

Most of all I absolutely do not want people on my ass with their little expectations. I don't give a shit. I made the code, GPL'd it and it's out there AS IS. Don't come to me like you expect me to care after it as if it was my child. Sometimes I'll care, sometimes I'll go beyond all measures of fuck giving. But it's not required.

Exploring a code base is a simple search algorithm. You can do it top down by starting from the main file and discovering new files from there. You can do it bottom up by looking for something specific that interests you and working backwards from there. You can choose to explore in breadth or depth at every turn. You can abort and search somewhere else if it looks like you're heading down an unrelated path.

Your complaints are just pure laziness. You want someone to literally come to you and give you a fucking tour of the project. Ain't happening kiddo. Not for free.

sage b/c you open the thread with complaints about the general state of software development, but irrationally blame it on opensauce (which at the least lets you even have access to the code).