Hello!I wanted to start a new project (such as Wikidex), that is, a wiki, how do I do it? I would like them to be as clear as possible by linking a link or something like that
Talk:Phabricator/Creating and renaming projects
Hi and welcome! Phabricator is for management of projects. If you want to set up a MediaWiki installation, please see "Set up and run MediaWiki" on https://www.mediawiki.org/. Thanks!
I'm a little confused why we apply the project creation policy to tags. Most systems allow you to input any arbitrary tags you want e.g. Flickr, Twitter - this is why tags are useful.
I agree, especially for tags, it makes no sense at all. I've proposed allowing meta-* tags to be created without such a crazy process in Phab: T132888, simply because I need to create a bunch of tags in order to get work done.
I really hate that we have such bureaucracy around tags in phabricator. To me it feels really odd and counter to the openness that I thought Wikimedia was founded on.
Tags do clutter the global namespace, so I don't want a million of them in there. That would make searches for actual projects, or tags relevant to me, less effective.
I am opposed to bureaucracy, but am not in favor of total anarchy either. It's just a matter of where to draw the line.
Hi @KSmith (WMF) thanks for joining the conversation! Could you elaborate how more tags would make searching difficult for you and how you feel that tags clutter the global namespace?
The rest of the web has this "anarchy" you descrie yet I can still find kittens despite the many tags on Instagram for kittens. Usually when this happens one becomes a defacto standard that people will use to ensure their kittens get seen. Likewise on Phabricator I would expect existing and popular tags to be used over the creation of new tags (creating a tag will always remain more tricky than using an existing one).
Looking at the list of newly created projects I often find project names that do not adhere to the rules described in this page. Some examples:
- WMEE IT projects, WMEE Wikidata infoboxes (no dashes between words, probably could be subprojects or milestones)
- Fundraising Sprint Window dressing is mostly olive oil (loooooooooong, no dashes, maybe should be milestone)
- Women in the Wikimedia movement: Conversations with communities, https://phabricator.wikimedia.org/project/view/3724/, etc. (ditto)
I am not sure how to proceed with all of these.
Thanks.
The guideline says "should", not must. So I do not see an issue.
I understand then it is okay to completly ignore this page from now on, or only some parts of it? I think it is in everybody's interest that project creation follows some sort of uniformity that while allowing teams to self-organize themselves allows the whole lot of Phabricator users to easily browse and understand the projects; and long project names make mobile Phabricator a real pain for example.
It's not okay to "ignore this page" (and I think nobody said that?). However there is a difference between the word "must" (think of "rules") and the word "should" (think of "recommendations").
Thank you. I guess RFC 2119 applies here as well with regards to said words then.
Do we have a naming convention?
We have AbuseFilter, CheckUser, CharInsert but MediaWiki-extensions-CentralAuth, MediaWiki-extensions-CategoryTree... Who's the responsible of creating this mess?
@MarcoAurelio: recently renamed CheckUser from "MediaWiki-extensions-CheckUser" to "CheckUser".
@Ciencia Al Poder I certainly advocated at first to keep the MediaWiki-extensions- prefix for all MediaWiki extensions. I asked about what should we do and @AKlapper (WMF) said that mantainers were free to remove the prefix from their projects. I renamed CheckUser yesterday somewhat following that advice, but I'd appreciate if we could stablish indeed some clarity, because IMHO the whole Phabricator project stuff is being slowly turned into a mess. I'd love to have a clear policy on naming and renaming projecs and that people stick to it. It'll be good for everyone, specially for newcomers, who will find more easily things if everything is standardized. Best regards.
See for example https://phabricator.wikimedia.org/project/profile/2446/ - Phabricator/Creating and renaming projects#Good practices for name and description says that multiple words should be connected with dashes in order to allow linking project names in Phabricator's markup. Plus, sprints are deprecated in favor of milestones, etc.
We do not have a naming convention when it comes to such prefixes. If "this mess" creates any problems I'd love to hear about the problems.
It would be great to have such a convention, so when assigning projects to a task about an extension you certainly know to start typing MediaWiki-Extension-Whatever instead of Whatever, although typing Whatever brings usually MediaWiki-Extension-Whatever as well. And for consistency, of course.
What I really don't understand is, if there was an initial convention to name such MediaWiki-Extension-* names (or at least they were imported with those names when coming from bugzilla), why not enforce and follow that? I couldn't believe it was left unrestricted just because "it looks nicer"...
There was no initial convention. The migration script from Bugzilla to Phabricator just used the format "$BugzillaProduct-$BugzillaComponent" to create the names of Phabricator projects.
@AKlapper (WMF) For me the mess is that I need a clear yes/no response on this question: Is it okay to rename MediaWiki-extensions-CentralAuth to CentralAuth (for example) or how new MediaWiki extensions projects should be named? MediaWiki-extensions-NEWEXTENSION or just NEWEXTENSION? I just don't want to be admonished afterwards for doing things wrong. Thanks.
Phabricator/Creating and renaming projects#Renaming projects implies that it is okay to rename.
The mess was created when people started removing the prefix.
As long as noone explains which problems "the mess" creates I have a hard time to see "a mess".
@Krenair I think I agree. On one hand, projects look "pretty" without the prefix, on the other hand, with the prefix they are more descriptive. I think we all would benefit on a clear guideline on how to name the extensions and recent extensions projects I created do carry the MediaWiki-extensions- prefixes. I think I'll stick to the MediaWiki-extensions- format still.
It's not just looking "pretty", it's a waste of users' time to put pointless information in front of them, and takes up screen space (which makes mobile Phabricating even more painful).
Ok, so try to reach consensus to remove the prefix from *all* MediaWiki-extensions-* projects?
There are a few places (like Vector-the-skin vs. Vector-the-extension) where there's a naming conflict (though that one is settled by dint of deleting the latter), but yeah, that'd help.
How does one propose or request a new project when that person is not a project creator? :D
(This is tangentially related to phab:T155017.)
Thanks for pointing that out! Fixed in https://www.mediawiki.org/w/index.php?title=Phabricator%2FCreating_and_renaming_projects&type=revision&diff=2349095&oldid=2342387
AKlapper: What are you objecting to in this edit? Requiring consensus over a shared resource like Phabricator seems completely reasonable to me.
This is related to phabricator:T150046, which is a large disappointment.
I'm objecting because it does not seem reasonable to me. See https://phabricator.wikimedia.org/T150046#2802308 and other comments.
I'm thinking about the practical aspects, and I foresee those conversations going like this:
- Alice: I need a private space to do my job.
- Bob: I object! I don't even know what you're doing, but there's no need for you to keep anything private. Everything you do should be visible to everyone in the world.
- Alice: I'm evaluating software that we might buy next year. I really do need to keep some of my work private, especially from the salescritters that we're dealing with.
- Bob: I object! There's no community consensus for you to have a private space on Phabricator!
- Alice: I can't do this work on Phabricator if I can't keep it private there.
- Bob: I object! We all share Phabricator. If you create a private project, then that'll somehow make Phabricator worse for the rest of us!
- Alice: *shrugs* Okay, I guess I'll use Asana instead. Goodbye.
When the person doing the work believes that it's best for that work to be done in private, then that work will be done in private. The only question is whether that's a private space on Phab or a private space elsewhere. Consequently, there's no realistic possibility of refusing "private projects"; there's only the possibility of encouraging people to have those private projects off Phab and therefore completely out of your sight.
Your comments there were addressed and you eventually said "This task does not feel like a good use of my time. I've explained my views more than once, so I'm leaving this conversation.", so why are you now objecting here?
@Whatamidoing (WMF), private projects *in* Phabricator are kept completely out of our sight (the most obvious example of this is that our administrators cannot enforce any oversight of such spaces because their powers do not extend over policies), which is the problem. Not to mention the fact that giving someone a private space in phabricator allows them to take public tasks and hide them away where noone else can see them. The fact that people can get away with doing Wikimedia things in private which do not need to be is not our problem if it does not occur on our sites, we should not allow it to happen in places we can control.
On Phab, you at least know that the private projects exist, and usually who's involved in it. Publicly requesting a private project is, itself, a form of transparency. In practical terms, the choice is between "know that the project exists on Phab" (minimal transparency on Phab) and "no transparency at all" (private projects are handled elsewhere). "Elsewhere" is still "our sites" and "places we can control": they will (and do) happen in WMF-controlled spaces that simply aren't available to the public. Consider, e.g., the long list of private wikis that the WMF has created: three billion internet users, 30 million registered editors – and fewer than 500 people (every one of whom has signed non-disclosure agreements) can read anything at collab.wikimedia.org beyond the main page.
I agree that it would be annoying to have a previously public task suddenly disappear. Everyone should exercise some discipline and care to prevent tasks that ought to be public from disappearing into private spaces. In my own experience, this has not been a major problem, but perhaps some individuals or teams have been less careful about it. But that's a risk regardless of whether it's your opinion that any given project ought to be private or not. Anybody could mark my tasks as being sensitive security matters, and from my POV, those tasks would disappear.
I'm objecting here because I also objected in Phabricator. If you think someone is "doing Wikimedia things in private which do not need to be", feel free to contact that someone (because that's what I'd do too). People are very free to "hide their tasks away" in other places than Phabricator if that makes you any happier (but I doubt). Your objections related to Phabricator Spaces don't solve any actual underlying problems.
I don't think that 'people can get away with it elsewhere' is a very convincing argument against making something against our rules, and the logical conclusion of it is terrible. I do think we need to ensure wikimedia principles are enforced when people are using our resources.
Andre: you seem to be talking in circles. In the linked Phabricator comment you write "As already explained, there was no need to address your concern beforehand, as per guidelines." Krenair attempted to update the guidelines and you reverted his edit. Now you're pointing back to your comment? This doesn't make any sense.
Phabricator is a shared resource and its use should be governed by consensus, as far as I'm concerned. Referencing other places, private or non-private, is a distraction. We're discussing Phabricator and practices surrounding it.
You (Andre), as I understand it, have advocated for a fairly restrictive policy for creating projects/tags in Phabricator. Why would private spaces in Phabricator be treated differently? It seems pretty clear to me that we should default to having everything be open and only grant exceptions with a demonstrated need, after reaching a consensus among Phabricator users and participants that such a need exists.
Andre: again, arguing that people can hide tasks in other systems is a distraction from what's being discussed here. We're discussing Wikimedia's installation of Phabricator and specifically your actions within it. While it's undoubtedly true that people can hide their tasks elsewhere, the point of this page and its associated talk page is to discuss Wikimedia's installation of Phabricator and its policies, guidelines, and processes. We (you, me, Krenair) can't control how others behave, but nobody is asking for that. They're asking that the place we do control, phabricator.wikimedia.org, be governed by openness and consensus.
Openness is provided by having to request (private) Spaces in a public task ("explain why there are repeatedly tasks in your project which should only be accessible by a defined group of people") and by documenting existing Spaces. Basic information about the (public and associated) project was requested and was provided. We seem to disagree if the provided information was sufficient - for my needs, it was, and it also was when the Ukrainian chapter asked for a Space and other previous Space creation requests.
Consensus is definitely desirable. When "missing consensus" is used as an argument to block people from being able to plan and perform their work it is rather counter-productive though.
The attempt to "update" the guidelines was putting a very restrictive policy in place for no convincing reasons. If you think that the current Space / project description is way too unclear (obviously I do not think so), feel free to contact the project maintainers, as with any other Phabricator project description. That is all possible already without having to "update" the guidelines.
> They're asking that the place we do control, phabricator.wikimedia.org, be governed by openness and consensus.
The consensus is: Groups can have private spaces, if they believe that they need them and can openly explain why they believe they need privacy. Therefore, creating such spaces is a true example of "being governed by openness and consensus".
Projects are cheap on Phabricator.
I'm a bit puzzled why we have so many restrictions in place around creating new projects. The world wide web wouldn't have been the success it was if people had to go through a request form to have a domain name, Twitter wouldn't have been so successful had hash tags required approval by an admin. This page lacks reasoning behind why we have a policy in place at all.
What are we worried about? Can we clarify?
I completely agree. It baffles me that we have such heavy-weight process around projects.
How do you register a domain name without a request form?
While it might involve the use of a form, the important distinction is that a domain name registration is automatically fulfilled and not generally scrutinized by your peers prior to being approved.
Sure, you can create any domain name you want. Then phishing comes to place with domain names too similar to existing ones. Same with twitter hashtags when there are several similar hashtags for the same concept. Which one to use? If you use only one, searches for that tag won't give you results for the other.
At least one person that is aware of the entire cloud of projects/tags should approve, checking first if there's not an existing project with the same purpose and it follows the naming conventions.
I think we need a more strict policy to be sincere. Projects are instruments to help people find and categorize things. To make things easier. That should work both ways: they should work for the team handling the stuff there, but also for external users who wish to find things. Actually I feel this is turning a bit into a mess. Regards.
There are no older topics