https://issues.dlang.org/show_bug.cgi?id=4763
--- Comment #4 from [email protected] --- (In reply to Andre from comment #3) > So we narrowed it down to one point, shall I change the title to reflect > this? Yeah, I suppose you can do that. > Regarding the follow up: > Is someone in particular responsible for this library or the proces of > deprecations for phobos? I don't think anyone is responsible for std.stdio or deprecations in particular. > Do we need to test the deprecation, provide a rationale and corrective > action? > > I'm willing to work on this as a way to learn the proces of contributing to > D, but some guidance is helpful. Are you familiar with git and GitHub? If not, you will have to learn the basics, at least. If you know your way around them, you can just clone the repositories and start making pull requests. See this page on the wiki: http://wiki.dlang.org/Starting_as_a_Contributor Regarding deprecations, I'm not sure what exactly the proper procedure is, i.e. what the phases are and how long they're supposed to be. Unfortunately, there doesn't seem to be any document on this. I would expect it to be on the wiki, but I couldn't find anything. You can ask about this in the forum, or you can just make a pull request with what feels ok to you and let reviewers correct you. Anyway, at some point you have to mark the thing `deprecated`, remove any references to it from the rest of the codebase, and finally (years later) remove the thing itself. Before all that happens, you have to get it through review, of course. And it's not clear yet if deprecating std.stdio.File.open is the way to go. Personally, I don't see a point in having `f.open(...)` when it does exactly the same as `f = File(...)`. But that's just me, and I only gave this a cursory look. --
